[mustache_kimono]

> Two examples that I can find

I think you may be misreading my point above. I am not arguing ZFS doesn't have bugs. That's nuts. I am arguing that the bug the parent says he has would be an extraordinary bug.

This is not just a bug that a scrub wouldn't find, but also it is a bug which an fsck would find. And it is not just a bug in the spacemaps or other metadata, but the 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.

[thatcks]

I am the parent, and any competent fsck should find these issues. Fsck traditionally explicitly verifies claimed free space against actual free space, and in a filesystem with ACLs it should also verify that filesystem level metadata like ACLs is sane, just as fsck verifies (for example) sane inode flags and inode field values. ZFS scrubs explicitly do not verify spacemap consistency or a lot of other sorts of consistency.

ZFS scrubs don't even verify that a filesystem's directory tree is acyclic and can reach every claimed in-use filesystem object, but I'm not aware of ZFS bugs in that area. This is because ZFS's 'metadata' for scrubs is much different than how it works in a traditional filesystem. To phrase it in conventional filesystem terms, ZFS has a big list of all in-use inodes, and it verifies the filesystem checksums by going through this list. The 'filesystem metadata' that a scrub verifies is the structure of this list of in-use inodes, plus some other things around the corners.