A loooong time age (OpenSolaris days) I had a system that had corrupted its zfs. No fsck was available because the developers claimed (maybe still do) that it's unnecessary.

I had to poke around the raw device (with dd and such) to restore the primary superblock with one of the copies (that zfs keeps in different locations on the device). So clearly the zfs devs thought about the possibility of a corrupt superblock, but didn't feel the need to provide a tool to compare the superblocks and restore one from the other copies. That was the point when I stopped trusting zfs.

Such arrogance…

▲

throw0101a 4 hours ago | parent | next [-]

> So clearly the zfs devs thought about the possibility of a corrupt superblock, but didn't feel the need to provide a tool to compare the superblocks and restore one from the other copies.

This mailing list post from 2008 talks about using zdb(8) to mark mark certain uberblocks an invalid so another one would be used:

* https://zfs-discuss.opensolaris.narkive.com/Tx4FaUMv/need-he...

ZDB = ZFS debugger. It's been there since the original Solaris release of ZFS.

> That was the point when I stopped trusting zfs.

As opposed to trusting other file systems and volume managers, which do not have checksums, and so you wouldn't even know about the problem in the first place?

▲

barrkel 7 hours ago | parent | prev | next [-]

That's a fine fit of pique - and I once had an awkward file on one of my zfs pools, about three pools ago - but how does it leave you better off, if you want what zfs offers?

	▲	Dylan16807 3 hours ago \| parent [-]
		> That's a fine fit of pique So you're rejecting a story about a real bug because...? > how does it leave you better off That's a really mercenary way to look at learning about your tools. But presumably they take smaller risks around zfs systems than they otherwise would.

▲

fvv 7 hours ago | parent | prev [-]

it's still the case even with now openzfs ? what do you trust now ?