alt Hacker News> Scrubs check hashes, not structure.
How is the structure not valid here? Can you explain to us how an fsck would discover this bug (show an example where an fsck fixed a similar bug) but ZFS could never? The point I take contention with is that missing an fsck is a problem for ZFS, so more specifically can you answer my 4th Q:
>> 4) If so, wouldn't this just be a bug, like (a bug in) fsck, not some fundamental limitation of the system?
So -- is it possible an fsck might discover an inconsistency ZFS couldn't? Sure. Would this be a fundamental flaw of ZFS, which requires an fsck, instead of merely a bug? I'm less sure.
You do seem to at least understand my general contention with the parent's point. However, the parent is also making a specific claim about a bug which would be extraordinary. Parent's claim is this is a bug which a scrub, which is just a read, wouldn't see, but a subsequent read would reveal.
So -- is it possible an fsck might discover this specific kind of extraordinary bug in ZFS, after a scrub had already read back the data? Of that I'm highly dubious.
> Can you show us how an fsck would discover this bug but ZFS could never?
I'd have to read closer to be certain, but if my understanding of it is correct, you'd have orphaned objects in the file system. The orphaned objects would be detectable, but would have correct hashes.
Here's a better example of one where scrub clearly doesn't catch it, but fsck would (and zdb does). The metaslab structure could be checked in theory, but isn't. https://neurrone.com/posts/openzfs-silent-metaslab-corruptio...
> if so, wouldn't this just be a bug, like (a bug in) fsck, not some fundamental limitation of the system?
It's not a bug or a fundamental limitation of the system, it's just that fsck != scrub, and nobody has written the code for fsck. If someone wanted to write the code, they could. I suspect it wouldn't even be particularly hard.
But fsck != scrub, and they catch different things.