5 ms·

It is not. `zpool scrub` walks every block in the pool, and implicitly, you do checksums and other things while doing that. That's it. It's not doing any sort

It is not. `zpool scrub` walks every block in the pool, and implicitly, you do checksums and other things while doing that. That's it. It's not doing any sort of logic bug repairs or cleanup or anything else. It's also not checking that you can, say, decrypt things, since that would mean you needed the keys to scrub.

db48x 3y ago
It really is better. The key difference to understand is that in ext4 any form of metadata corruption which can be automatically fixed requires you to take the filesystem off–line (to unmount it), and then run fsck. Meanwhile with zfs, any form of metadata corruption which can automatically be fixed is simply fixed right on the spot, transparently. In truth fsck is a wart, a kludge, a bag on the file system design.
- rincebrain 3y ago
  I am passingly acquainted with ZFS. The key thing to realize is that you can't, actually, automatically fix every problem, sometimes you have found a logic problem which results in an impossible outcome and you need someone to manually clean it up. In a world without flaws, it would be great to never need that. But the thing about theory and practice is that in theory, they never differ, but in practice...
  - db48x 3y ago
    I know that. But fsck only fixes the ones that it can fix automatically. With anything else, you are completely on your own. Get a hex editor and go to town. With zfs, if there is some kind of problem that cannot be automatically fixed then at least you have one more tool available: zdb. It’s a _debugger_ for zfs filesystems. It will show you everything, more than you ever wanted to know. It is way better for fixing problems than any hex editor.
    - rincebrain 3y ago
      zdb is read-only. It's not fixing anything, just telling you what's going on.
      - db48x 3y ago
        Don’t be an idiot. You can fix more with zdb and a hex editor than you can with the hex editor alone.
        rincebrain 3y ago
        That seems rather rude. The discussion was about the need for tools to make it easier to handle cases where you couldn't automatically handle repairing them, and your statement was that zdb is very useful, which is true, but it doesn't fix anything. fsck for various filesystems has a bunch of common cases like "this is an orphaned file, should I save it or mark it free?", and something similar would indeed be useful for a number of failure cases in ZFS which require more explicit instruction on what to do about it because you can't easily automatically resolve it. `zpool scrub` is very useful, but ZFS could still benefit from automated tooling to handle some common failure modes, not just let you write bespoke tooling every time.
        db48x 3y ago
        > fsck for various filesystems has a bunch of common cases like "this is an orphaned file, should I save it or mark it free?" This is an example of an automated fix that zfs just handles transparently, without needing to prompt the user. Or it would, if zfs could even have orphaned files, which it cannot. I don’t know why you think this is such a win for fsck, which doesn’t even bother to give you any idea what the file was. It doesn’t try to show you the contents, and it probably doesn’t know what the file was called, or why it was deleted. Or even if it _was_ deleted; a file could be orphaned merely because the data was written but the write to the directory entry got lost. The user has nothing to go on and just guesses, or says `y` for everything. Useless. > `zpool scrub` is very useful, but ZFS could still benefit from automated tooling to handle some common failure modes This is precisely and exactly what scrubbing does! All failure modes that can be automatically fixed, whether they are common or not, are transparently fixed without even needing to unmount anything. zdb is there for the really rare cases where there is so much damage to the filesystem that zfs cannot even mount it safely. Other filesystems don’t have anything like it.

db48x 3y ago

It really is better. The key difference to understand is that in ext4 any form of metadata corruption which can be automatically fixed requires you to take the filesystem off–line (to unmount it), and then run fsck. Meanwhile with zfs, any form of metadata corruption which can automatically be fixed is simply fixed right on the spot, transparently. In truth fsck is a wart, a kludge, a bag on the file system design.

rincebrain 3y ago
I am passingly acquainted with ZFS. The key thing to realize is that you can't, actually, automatically fix every problem, sometimes you have found a logic problem which results in an impossible outcome and you need someone to manually clean it up. In a world without flaws, it would be great to never need that. But the thing about theory and practice is that in theory, they never differ, but in practice...
- db48x 3y ago
  I know that. But fsck only fixes the ones that it can fix automatically. With anything else, you are completely on your own. Get a hex editor and go to town. With zfs, if there is some kind of problem that cannot be automatically fixed then at least you have one more tool available: zdb. It’s a _debugger_ for zfs filesystems. It will show you everything, more than you ever wanted to know. It is way better for fixing problems than any hex editor.
  - rincebrain 3y ago
    zdb is read-only. It's not fixing anything, just telling you what's going on.
    - db48x 3y ago
      Don’t be an idiot. You can fix more with zdb and a hex editor than you can with the hex editor alone.
      - rincebrain 3y ago
        That seems rather rude. The discussion was about the need for tools to make it easier to handle cases where you couldn't automatically handle repairing them, and your statement was that zdb is very useful, which is true, but it doesn't fix anything. fsck for various filesystems has a bunch of common cases like "this is an orphaned file, should I save it or mark it free?", and something similar would indeed be useful for a number of failure cases in ZFS which require more explicit instruction on what to do about it because you can't easily automatically resolve it. `zpool scrub` is very useful, but ZFS could still benefit from automated tooling to handle some common failure modes, not just let you write bespoke tooling every time.
        db48x 3y ago
        > fsck for various filesystems has a bunch of common cases like "this is an orphaned file, should I save it or mark it free?" This is an example of an automated fix that zfs just handles transparently, without needing to prompt the user. Or it would, if zfs could even have orphaned files, which it cannot. I don’t know why you think this is such a win for fsck, which doesn’t even bother to give you any idea what the file was. It doesn’t try to show you the contents, and it probably doesn’t know what the file was called, or why it was deleted. Or even if it _was_ deleted; a file could be orphaned merely because the data was written but the write to the directory entry got lost. The user has nothing to go on and just guesses, or says `y` for everything. Useless. > `zpool scrub` is very useful, but ZFS could still benefit from automated tooling to handle some common failure modes This is precisely and exactly what scrubbing does! All failure modes that can be automatically fixed, whether they are common or not, are transparently fixed without even needing to unmount anything. zdb is there for the really rare cases where there is so much damage to the filesystem that zfs cannot even mount it safely. Other filesystems don’t have anything like it.