Login
You're viewing the discuss.systems public feed.
  • Oct 16, 2026, 4:58 PM

    I'm seeing lots of people on my timeline talk about ZFS as a pleasant side benefit of switching to one of the BSDs so I think it's time for a public reminder that the ZFS devs think they don't need to give you a real fsck—one that actually checks the consistency of the on-disk data structure and repairs it if necessary. 'zfs scrub' is like RAID scrub, it only does block checksums.

    This inexcusable act of hubris once forced me to restore an entire file server from offline backup.

    💬 2🔄 3⭐ 5

Replies

  • 💬 0🔄 0⭐ 0
  • Oct 16, 2026, 6:48 PM

    @c64whiz As far as I know, you only get ZFS if you actively choose it; the defaults are all older, more conventional FFS-derived file systems. I have not exhaustively checked.

    💬 0🔄 0⭐ 0
  • Oct 17, 2026, 1:28 AM

    @zwol I didn't think that's true. I've understood that all data on-disk has a checksum- data and metadata/structure alike. If (meta)data is damaged on-disk, the way of repairing it is to copy it from a redundant copy, not fill in the blanks with zeroes and guesses like fsck or hardware raid might do. Using zfs without mirroring or raidz is a recipe for disaster, and that should be made more clear. But storing important data without a redundancy scheme at all is a recipe for disaster.

    💬 0🔄 0⭐ 0
  • Oct 17, 2026, 1:49 AM

    @ClemFandango This line of reasoning doesn't cover the case where a logic error in the filesystem driver causes semantically invalid data to be written to disk. That kind of corruption can't be detected by block checksums, and it affects all copies of the damaged data structure.

    This is what made me have to recover multiple terabytes from backup, and this is the class of error that a proper fsck is designed to repair.

    💬 1🔄 0⭐ 0
  • 💬 0🔄 0⭐ 0