News for hackers. Stuff that matters.
Re:Filesystems can experience at least three different sorts... by chungy on Saturday March 12, 2022 @01:06PM (#30653351)
scrub is exactly the "zfs fsck" that people claim they pine for. It is part of the file system's design philosophy that every administrative action happens on online pools, which even includes correcting errors in the file system. Making it so you don't have to take your system offline is a feature, not a bug.
Re:Filesystems can experience at least three different sorts... by rincebrain on Saturday March 12, 2022 @02:12PM (#30653935)
I think the difficulty in these conversations is that people say they want a "fsck for ZFS", when often they don't mean they want "periodic sanity checks for ZFS", they mean they want something like "xfs_repair -d* for ZFS" or "extundelete for ZFS" - that is, a tool for salvaging beyond-the-pale mangling such that your pool is no longer able to be imported.

* - not a perfect analogy, but I'm hard-pressed to think of good off the shelf tools for what they're looking for. I guess reiserfsck's infamously side-effect laden --rebuild-tree would probably be closest...

(I am acquainted with zdb -r and import -T; neither helps you if there's not enough metadata consistent to get enough of a pool structure in memory to 'import', but one could still conceivably salvage some data in that case.)

Re:Filesystems can experience at least three different sorts... by XorNot on Saturday March 12, 2022 @07:07PM (#30656440)
Technically this is the various, increasingly dangerous zfs import commands though.

The point of those is that the only time a pool is truly unusable is when you can't even import it.

Re:Filesystems can experience at least three different sorts... by rincebrain on Sunday March 13, 2022 @06:50AM (#30660088)
Yes, -F, -X, and -T.

The issue is, I think, people are expressing a desire for a tool that can still salvage data even when you've gone through all the (128/N) -T options and found them all unhelpful.

Re:Filesystems can experience at least three different sorts... by siebenmann on Saturday March 12, 2022 @03:12PM (#30654476)
Unfortunately ZFS scrubs are not as complete as fsck on a regular filesystem. ZFS scrubs only verify that checksums are intact. They don't verify that filesystem level metadata is correct (although they do verify ZFS structural metadata as part of walking everything, which isn't the same thing). For example, a ZFS scrub will not detect that a filesystem inode has certain sorts of crazy or invalid contents, or damaged ACLs. It doesn't even necessarily verify that the filesystem directory structure is correct and intact.

For more on this, see https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSScrubLim...

(The tl;dr is that a fsck on an ordinary filesystem has to walk the directory tree to find everything. However, ZFS maintains a separate list of active inodes and a scrub can just walk over them and check the checksums of all of their data blocks. It doesn't have to, for example, read a directory's contents to find further files to scrub.)