(no title)
wereHamster | 1 month ago
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|1 month ago
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?
rincebrain|1 month ago
fvv|1 month ago
barrkel|1 month ago
Dylan16807|1 month ago
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.