缓存有一定概率导致ReFS分区损坏 Topic is solved

[Aesisstrong]

已经重新写三次了，长话短说：

1.我使用PrimoCache缓存ReFS分区，仅使用二级缓存，并选择“下次开机时重置缓存”，之后便休眠电脑（注：因为特殊原因，此电脑休眠相当于直接关机（类似PCHunter的强制关机），即启动时无法恢复休眠状态），此时硬盘灯一直闪（因为这时还有缓写数据），之后电脑便成功休眠（这时PrimoCache已经把缓存数据写入了...吧？）
2.之后我启动电脑，发现被缓存盘已损坏，提示“卷修复不成功”，此时使用ReFSUtil的快速扫描阶段失败，提示“发生了数据完整性校验和错误。文件流中的数据已损坏。”并且这时DiskGenius（新版支持ReFS）无法查看分区文i件，显示为空。（后面的“卷修复不成功”都是可以查看的。）
3.当我恢复数据时发现，因为“卷修复不成功”时其仍在读写数据来《抢救数据》，所以导致大约500个G的数据丢失（接近80%）。

刚开始我以为是ReFS分区的锅，于是我在虚拟机测试，死活搞不坏ReFS分区（排除虚拟磁盘文件（VHDX）无法打开的情况和“参数错误”错误（这个也许可以手动修复，而且它不会像“卷修复不成功”一样覆写数据）），直到我看到这个论坛关于ReFS分区错误的报告。

于是我开始测试PrimoCache+ReFS的安全性，果然损坏了（即“卷修复不成功”错误（出现了2次，概率够高了））。之后我测试PrimoCache+NTFS的安全性，非常安全，没有出现分区打不开的情况（排除虚拟磁盘文件（VHDX）无法打开的情况）。

为了实验的严谨性，我打算使用现实世界的硬件（U盘）进行测试。我使用一个128G的U盘，测试PrimoCache+NTFS的安全性，拔插了8次左右完全没有损坏，之后测试单ReFS分区，不使用PrimoCache，更是拔插了十几次没有任何问题。最后测试PrimoCache+ReFS，仅仅拔插到第6次左右就提示“卷修复不成功”，此时ReFS依然读写分区，应该是在《抢救数据》。

附加测试：又重新在U盘测了PrimoCache+NTFS，共15次无问题；单ReFS，共17次无问题；PrimoCache+ReFS，第7次出现“卷修复不成功”。

如果需要“卷修复不成功”错误的分区数据，请回复我，我将克隆出来提供研究。

吐槽：说无法复现也太不负责了吧，这么大的概率，而且ReFS原本就没有问题（在虚拟机里可是开了“更好的性能”策略，有Windows自己的缓存，那种缓存怎么没事呢？）

PrimoCache版本：4.2.0服务器版；内核版本：4.2.0.6 Windows版本：10 专业工作站版；版本号：1909；操作系统版本：18363.592

别问我U盘怎么格式化ReFS分区的，换成cfadisk驱动就行了。（警告：只有安装了这个驱动的系统才能识别到U盘的ReFS分区，其他电脑是无法识别的，别指望U盘能更安全，而且这个驱动要开“禁用驱动程序强制签名”（新的系统就算开这个也不能使用无签名驱动，只能用自签名驱动））。


修正：我发现了一个错误，上面我说的休眠电脑是在测试UPS，软件设置了系统关闭2分钟后关闭UPS，也许PrimoCache并未完全写入缓写数据就被UPS直接断电，这是设置上的一个问题，不过也说明PrimoCache缓写未写入+ReFS会出现问题，但为啥Windows的缓写就没出过问题呢？也许在ReFS缓写的机制要修改一下。

目的：主要是因为ReFS原本要的就是数据安全，而PrimoCache的到来却让其经常出现“卷修复不成功”，而且这个错误会不断覆写数据导致无法恢复，这显然不太好。而老旧的NTFS竟然在这种情况下不会损坏！这非常的不合理！我想知道为什么会出现这种情况，到底是PrimoCache的Bug还是ReFS设计与PrimoCache不兼容导致的呢？

[Support]

1.我使用PrimoCache缓存ReFS分区，仅使用二级缓存，并选择“下次开机时重置缓存”，之后便休眠电脑（注：因为特殊原因，此电脑休眠相当于直接关机（类似PCHunter的强制关机），即启动时无法恢复休眠状态），此时硬盘灯一直闪（因为这时还有缓写数据），之后电脑便成功休眠（这时PrimoCache已经把缓存数据写入了...吧？）

非常感谢您的反馈！请问您的设置开启了延时写入了吗？您方便按下面的说明把您的缓存配置截图发一下吗？谢谢！
https://kb.romexsoftware.com/zh-cn/2-pr ... leshooting

PS. 因异常关机（包括蓝屏死机）等导致缓写数据不能写入硬盘而引起的数据丢失文件系统损坏的情况是不在我们测试列表中的。我们测试的是正常使用情况下PrimoCache与ReFS系统的兼容性。根据我们的研究和测试，以及结合用户的反馈，目前看下来ReFS系统主要还是设计用于服务器操作系统，并且直到Server 2019 系统才开始很稳定。

[Aesisstrong]

1.我使用PrimoCache缓存ReFS分区，仅使用二级缓存，并选择“下次开机时重置缓存”，之后便休眠电脑（注：因为特殊原因，此电脑休眠相当于直接关机（类似PCHunter的强制关机），即启动时无法恢复休眠状态），此时硬盘灯一直闪（因为这时还有缓写数据），之后电脑便成功休眠（这时PrimoCache已经把缓存数据写入了...吧？）

非常感谢您的反馈！请问您的设置开启了延时写入了吗？您方便按下面的说明把您的缓存配置截图发一下吗？谢谢！
https://kb.romexsoftware.com/zh-cn/2-pr ... leshooting

PS. 因异常关机（包括蓝屏死机）等导致缓写数据不能写入硬盘而引起的数据丢失文件系统损坏的情况是不在我们测试列表中的。我们测试的是正常使用情况下PrimoCache与ReFS系统的兼容性。根据我们的研究和测试，以及结合用户的反馈，目前看下来ReFS系统主要还是设计用于服务器操作系统，并且直到Server 2019 系统才开始很稳定。

是启动了延迟写入，在描述当中有写“此时硬盘灯一直闪（因为这时还有缓写数据）”，就是有很多缓写内容。目前我放弃给ReFS缓写数据，但可以将当时的配置模拟出来发一下：

1.png

2.png

3.png

主要是因为NTFS在突然断电+缓写的情况都不会坏，所以才有疑问：“ReFS这么“安全”，怎么会坏呢？”

另外我还发现如果在卷上开启缓写，对卷进行扩展操作会导致分区错误，出现“参数错误”。卷依然能访问，但容量不正确，在磁盘管理中显示的是扩展后的容量，在资源管理器中显示的是扩展前的容量。目前解决方法就是关闭缓存后在分区工具重新找到扩展前容量的分区，在关闭缓存的情况下重新进行扩容。

如果PrimoCache是将整个硬件缓存也许就没有这么多问题了吧（指ReFS损坏的问题）？建议添加缓存整个硬件而不是单个分区，不过扩展卷的错误也许是分区表的问题吧？PrimoCache拦截了操作分区表的行为？

[Support]

不建议延时时间设置“无限”，即使“空闲”写入模式。如果要设置写缓的话，建议还是小点的延时时间比较好，延时时间越长，最后需要刷入的数据量就可能越大。正常情况下PrimoCache有机制保证缓写数据全部刷入后Windows才关机或休眠，但是您这里的问题是UPS没有提供足够的时间来供电确保所有缓写数据刷入硬盘，所以就会导致异常关机引起数据丢失。

主要是因为NTFS在突然断电+缓写的情况都不会坏，所以才有疑问：“ReFS这么“安全”，怎么会坏呢？”

NTFS 在突然断电时也可能出现文件系统损坏，只是概率比较低。ReFS 可能对文件系统元数据依赖比较大，而且初期可能还有很多bug，之前我们发现Windows10下的ReFS在Windows 8中打开就损坏（无任何缓存）。

另外我还发现如果在卷上开启缓写，对卷进行扩展操作会导致分区错误，出现“参数错误”。卷依然能访问，但容量不正确，在磁盘管理中显示的是扩展后的容量，在资源管理器中显示的是扩展前的容量。目前解决方法就是关闭缓存后在分区工具重新找到扩展前容量的分区，在关闭缓存的情况下重新进行扩容。

如果某个卷设置了缓存，PrimoCache会阻止该卷上的容量变化，因为缓存任务依赖于该卷的容量大小。需要先停止缓存后再进行分区容量改变。

[Aesisstrong]

NTFS 在突然断电时也可能出现文件系统损坏，只是概率比较低。ReFS 可能对文件系统元数据依赖比较大，而且初期可能还有很多bug，之前我们发现Windows10下的ReFS在Windows 8中打开就损坏（无任何缓存）。

注：ReFS并不向上兼容，这不是Bug，新版本的ReFS在旧版本系统中无法识别。

另外我进行了更加详细的测试，终于发现问题所在：
首先我测试了当PrimoCache+ReFS只开启缓读的情况，是没有问题的（排除“参数错误”，因为没有缓存也会出现这个错误，但不会出现“卷修复不成功”）。之后我测试PrimoCache+ReFS只开启缓写的情况，有概率出现“卷修复不成功”。PrimoCache+ReFS只开启缓写且插入时把缓存删除，插入后再添加缓存，排除了PrimoCache和ReFS插入时的卷修复出现冲突的情况，仍然有概率出现“卷修复不成功”。

但之后是重头戏：当我使用批处理测试“PrimoCache+ReFS只开启缓写且插入时把缓存删除”，测试了50次只出现了3次“参数错误”，没有“卷修复不成功”，我非常疑惑。之后我便发现，用这种方式写入时，缓写数据块百分比始终占满，似乎是“顺序写入”，且紧急写入大于常规写入，我便测试使用断续写入。断续写入即当缓写快满时暂停写入，之后让其空闲写入一部分后再重新继续，即百分比变化为0%、30%、70%、98%、50%、75%、34%、88%、66%、99%，让其空闲写入一部分，之后让其紧急写入一部分，使百分比在30%到100%上下浮动。反复进行多次这种极端写入方式，在某个时间点突然拔出。当重新插入时，有极大概率出现“卷修复不成功”，与“顺序写入”形成鲜明对比：测试大概6~7次便出现3次“卷修复不成功”，而“顺序写入”测试了50次没有一次出现“卷修复不成功”。

可能就是因为没有按照ReFS命令的顺序写入，导致写入了“未来”的数据块而“过去”的数据块没有写入，即10秒前的数据写入了，但20秒前的数据并没有写入，导致ReFS文件系统紊乱，出现错误。

你们可以按照这种方式测试一下，如果真的是这样（我的测试结果仅供参考），那么建议加入一个“写入时按照系统要求的写入顺序写入”选项（被裁剪数据块可以直接从顺序列表中删除），也许可以防止这种问题...吗？

[Support]

非常感谢您的详细测试！虽然您测试的还是在异常断电（写缓没有完全刷入）的场景，但对于我们研究ReFS也有很大启发，谢谢！

[Aesisstrong]

非常感谢您的详细测试！虽然您测试的还是在异常断电（写缓没有完全刷入）的场景，但对于我们研究ReFS也有很大启发，谢谢！

感谢你们的回复和注意，如果你们有更新要发布，建议加入“写入时按照系统要求的写入顺序写入”选项，这应该不是特别困难，以便我继续测试，谢谢！如果发现在这种情况下极难损坏，即可在这个选项上加上（ReFS文件系统建议勾选，以防分区损坏）。这对ReFS用户有很大帮助，以免不明不白数据丢失。

如果你们加入了这个选项，我将会测试更多次，以支持这个猜想。

[spvwh]

refs问题就是一个玄学，正常关机，再开机refs盘就不能识别，变成raw盘，只能格式化，遇到过几次，不敢再用refs

[Aesisstrong]

refs问题就是一个玄学，正常关机，再开机refs盘就不能识别，变成raw盘，只能格式化，遇到过几次，不敢再用refs

请问您的使用方式是如何的，能否复现，如果可以描述详细的复现方式，我会进行一些测试，因为我很想知道ReFS的安全性以及其可能的Bug。

[spvwh]

refs问题就是一个玄学，正常关机，再开机refs盘就不能识别，变成raw盘，只能格式化，遇到过几次，不敢再用refs

请问您的使用方式是如何的，能否复现，如果可以描述详细的复现方式，我会进行一些测试，因为我很想知道ReFS的安全性以及其可能的Bug。

外置移动usb硬盘，开了写缓存，refs格式，正常关机，再开机就成了raw盘
这个问题是随机的，不知道哪次关机开机就会发生，就再也不用refs了