5 ms·

This is one of the key strengths of ZFS. Your log file would be silently corrupted without checksumming.

• kogir 12y ago
  I agree completely. Much better to know than not. But having no option to knowingly just lose inconsistent data and move on is a bummer.
  • dsturnbull2049 12y ago
    A corrupt file in ZFS indicates multiple broken disks. Copy the file in from a backup, use raidz3 and/or set copies=2 for critical zfs volumes. https://blogs.oracle.com/relling/entry/zfs_copies_and_data_protection https://blogs.oracle.com/relling/entry/zfs_copies_and_data_p...
• rodgerd 12y ago
  Regardless, it's still frustrating that so many failure modes for ZFS have an answer of "blow it all away and start again". And that's with Solaris/ZFS.
  • laumars 12y ago
    There are other ways to fix issues with ZFS pools without having to "blow it all away and start again". In the example that started this conversation fork, there's a simple parameter to pass to the zpool utility that would have saved the OP from dropping his pool: zpool clear tank ZFS does actually come with a decent set of tools for fixing and clearing faults - which I'm starting to realise isn't as widely known (possibly because people rarely run into a situation where they need it?) Anecdotally speaking; I've ran the same pool for years on consumer hardware and that pool has even survived a failing SATA controller that was randomly dropping disks during heavy IO and causing kernel panics. So I've lost count of the number times ZFS has saved my storage pool from complete data loss where other file systems would have just given up.
    • deleted 12y ago
      [deleted]
      • laumars 12y ago
        Indeed, however that's all dropping and recreating the pool would do as well. The file would still be corrupt.