4 ms·

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

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…

fvv 8mo ago
it's still the case even with now openzfs ? what do you trust now ?
barrkel 8mo ago
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 8mo ago
  > 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.
throw0101a 8mo ago
> 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-help-invalidating-uberblock 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?
- rincebrain 8mo ago
  That's not using zdb to change anything - it's readonly, all the time. The person reached out and used dd on the disk to corrupt the copies of the uberblock with bad data so that ZFS would be forced to use the older ones (what zpool import -T does, basically, but doing it the hard way).

fvv 8mo ago

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

barrkel 8mo ago

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 8mo ago
> 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.

throw0101a 8mo ago

> 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-help-invalidating-uberblock 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?

rincebrain 8mo ago
That's not using zdb to change anything - it's readonly, all the time. The person reached out and used dd on the disk to corrupt the copies of the uberblock with bad data so that ZFS would be forced to use the older ones (what zpool import -T does, basically, but doing it the hard way).