确实遇到过 bit rot 导致部分数据损坏的情况,也多次看见各种场景下 bit rot 的案例(本站好像就有, https://v2ex.com/t/695160 第 119 条回复可确定 bit rot )所以我对文件系统的数据完整性功能比较看重。
因为用的 Windows 轻薄本只能插一块 M.2 硬盘,研究了一种单盘抗 bit rot 的方案:自制了一个小工具每 10 分钟 rclone sync
客户端侧加密单向同步到 Google Drive 一遍。因为开启了 ReFS 完整性的 Enforced ,手动破坏 VHD 文件实验确定 ReFS 确实能阻止对损坏文件的读取,从而防止 rclone 上传损坏文件。因为发现在尝试读取损坏文件时会触发一个 System EventID=133 的事件,我还做了一个 133 事件时自动从 Google Drive 拉回对应完好文件的功能。不知道是不是单盘的原因,Microsoft\Windows\Data Integrity Scan
这个 Scrubber 总是不工作,在 1 秒内退出,扫描不出任何错误,所以还做了一个每天凌晨 3 点全盘读取一次的功能(我嫌麻烦从来不关电脑也不睡眠)。
但我最近多次在 Reddit 等地方看到 ReFS 的负面文章(尽管在我手动破坏 VHD 的实验中表现的似乎还不错,除了那个 Scrubber 无法工作外没有出现预期外结果,但那些 Reddit 上发帖的用户做了自动化测试脚本,比我的实验覆盖的用例多不少),同时我还有一台使用 Apple M2 Pro 处理器的备用笔记本(无法在物理机上直接安装 Windows ,macOS 下似乎没有支持文件内容 checksum 的文件系统)想问问有没有什么更好的实践。
我也考虑过不基于文件系统的实现,定期全量校验文件 hash ,但这种情况下除了无法防止因硬盘固件等问题导致数据在写入硬盘前就出现错误外(我的现有方案也无法纠正这种情况的错误),无法拦截错误数据的读取,更重要的是无法准确判断是否是用户的主动更改(发现了一个软件在保存文件时不会更新文件的修改时间,不知道是用了什么办法写入数据的)
我必须使用的生产力软件没有 Linux 版本,也完全无法在 wine 中工作,因此请不要推荐使用 Linux ,以及用奇怪的办法在 Windows 下使用 Linux Only 的文件系统,例如 ZFS 。
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.