有没有什么好的策略可以主动检测 Greyhole 池中的数据损坏。
假设发生以下一系列事件。
c:\> copy swiss_bank_account.txt \\greyhole\safe_documents
Greyhole does its thing and replaces:
safe_documents/swiss_bank_account.txt with -> /mnt/pool1/safe_documents/swiss_bank_account.txt
and creates a backup file:
/mnt/pool2/safe_documents/swiss_bank_account.txt
/mnt/pool2 suffers a random failure, corrupting swiss_bank_account.txt - It goes un-noticed because it's the secondary.
/mnt/pool1 suffers a random failure - Crap... now both my redundant copies are corrupt.
有哪些好的策略可以主动检测 Greyhole 等 JBOD 样式重复阵列中的损坏?
如果我没记错的话,即使是三向复制也并非万无一失。如果驱动器发生灾难性故障,您只能检测出两个幸存副本之间的差异,而无法解决。
我能想到的可行系统有:
- 跨校验和文件系统(如 btrfs)的三向复制。
- 三向复制并希望所有故障都是不相关的。
- 奇偶校验工具的 Chron-job 应用程序。
- 连接 Greyhole 以在写入时运行奇偶校验工具。
- Chron-job 扫描数据一致性。
除了选项 1 和 2 之外,所有这些选项似乎都比我想在家庭服务器上投入的工作量要多。有人有什么建议吗?
答案1
您假设损坏会悄无声息地出现,这是一种数据完整性损失的形式,文件系统和存储硬件开发人员都在积极努力避免这种情况。很有可能块驱动程序会注意到读/写过程中出了问题并大喊大叫,此时就由更高级别的软件(Greyhole)来处理故障。或者,如果块驱动程序没有注意到,文件系统驱动程序会注意到。
我认为你担心的情况是如果宇宙射线或某种物质在不同设备上扰乱了一个文件的比特,Greyhole 如何处理这个问题?
你基本完蛋了,所以如果你担心的话,你应该选择 3 倍冗余。然而,三台设备同时出现故障的可能性是很多少于只有一个出现问题,所以这是一个相当极端的情况。
答案2
使用 Greyhole 特定解决方案来回答:使用--checksums
以下选项--fsck
:
-k, --checksums
Read ALL files in your storage pool, and check that file copies
are identical. This should identify any problem you might have with your
file-systems.
NOTE: this can take a LONG time to complete, since it will read everything
from all your drives!
您需要确保您的服务器可以发送电子邮件,并--email-report
同时使用该选项,以便在完成后接收报告。(如果您愿意,报告也会保存到磁盘。/usr/share/greyhole/
我认为……)