12 ms·

I certainly know what ZFS was designed for. I've been working with replicated checksummed file systems for decades, including WAFL, NetApp's file system, which

I certainly know what ZFS was designed for. I've been working with replicated checksummed file systems for decades, including WAFL, NetApp's file system, which ZFS was "inspired" by (see the Sun vs NetApp lawsuit). They had both block- and sector-based checksums in 2002, albeit designed for RAID-4. I wholeheartedly endorse checksummed file systems for maximum data integrity. ZFS will not protect you (by default) against bit flips in memory (please use ECC) or kernel bugs. If the disk buffer is corrupted in the kernel, on its way to the file system layer for dispatch, ZFS will happily checksum and perfectly store the bad data. Checksums are like Rust's borrow checker: a very good idea that makes your data safer, but not a panacea that prevents all errors. Finally, as with all complex file systems, ZFS is notorious for difficulty in recovering from multi-bit errors, often requiring "pool surgery" and multi-day disk scrubs to remount the file system. Perhaps your data is eventually recoverable, but do you have a week to finish the scrub to get it back online? If any this sounds unlikely to you, I assure you, it is! But it can happen, I've seen it happen, and for things that really matter, one of your backups should always always always be logical.

tomxor 6y ago
> ZFS will not protect you (by default) against bit flips in memory (please use ECC) or kernel bugs. If the disk buffer is corrupted in the kernel, on its way to the file system layer for dispatch, ZFS will happily checksum and perfectly store the bad data. That's all very well but I don't see how your suggestions of doing archive backups make this any less of a problem, you are just operating on a higher level layer with the same problems. I'm also fairly sure most servers are built with ECC these days, I know my IaaS provider uses it. > Finally, as with all complex file systems, ZFS is notorious for difficulty in recovering from multi-bit errors, often requiring "pool surgery" and multi-day disk scrubs to remount the file system. Perhaps your data is eventually recoverable, but do you have a week to finish the scrub to get it back online? I cannot claim to have extensive ZFS war stories but I have had errors on a bad block device in a mirrored pool, but with this type of pool it does not affect mountability or performance. The only annoying performance issue affecting mountability I've had so far was when accidentally filling up a pool that had dedup enabled, since it struggles to function in the reserve area.

tomxor 6y ago

> ZFS will not protect you (by default) against bit flips in memory (please use ECC) or kernel bugs. If the disk buffer is corrupted in the kernel, on its way to the file system layer for dispatch, ZFS will happily checksum and perfectly store the bad data. That's all very well but I don't see how your suggestions of doing archive backups make this any less of a problem, you are just operating on a higher level layer with the same problems. I'm also fairly sure most servers are built with ECC these days, I know my IaaS provider uses it. > Finally, as with all complex file systems, ZFS is notorious for difficulty in recovering from multi-bit errors, often requiring "pool surgery" and multi-day disk scrubs to remount the file system. Perhaps your data is eventually recoverable, but do you have a week to finish the scrub to get it back online? I cannot claim to have extensive ZFS war stories but I have had errors on a bad block device in a mirrored pool, but with this type of pool it does not affect mountability or performance. The only annoying performance issue affecting mountability I've had so far was when accidentally filling up a pool that had dedup enabled, since it struggles to function in the reserve area.