> Can you give a more concrete example of what you mean?

There's been several instances. For example, the send/receive code has had bugs leading to cases[1] where the checksum and hence scrub look fine but the data is not.

edit: the recent block cloning has also had some issues, eg[2][3].

I'm pretty sure it's also possible for hardware errors like bad memory to cause the data to get corrupted but the checksum gets computed on the corrupted data, thus it looks ok when scrubbed.

[1]: https://github.com/openzfs/zfs/issues/4809

[2]: https://github.com/openzfs/zfs/issues/15526

[3]: https://github.com/openzfs/zfs/issues/15933

▲

mustache_kimono 2 hours ago | parent | next [-]

> There's been several instances.

I think you're missing the 2nd feature to the parent's point that I take issue with, which is this is not just a bug that a scrub wouldn't find, but it must also be a bug which an fsck would find.

The parent's point is -- ZFS should have an fsck tool because an fsck does something ZFS cannot do by other means. I disagree. Yes, ZFS has bugs like any filesystem. However, I'm not sure an fsck tool would make that situation better?

	▲	magicalhippo 2 hours ago \| parent [-]
		> I think you're missing the 2nd feature to the parent's point that I take issue with You're right, I did gloss over that point. I guess it should be noted that a lot of what fsck does[1] on say ext4 is something ZFS does on pool import, like replying the journal (ZIL) or trying older superblocks (uberblocks[2]). In that regard it's acting more like XFS[3] from what I can see, which just exits with 0. [1]: https://linux.die.net/man/8/fsck.ext4 [2]: https://openzfs.github.io/openzfs-docs/man/master/8/zpool-im... [3]: https://linux.die.net/man/8/fsck.xfs

▲

SubjectToChange 4 hours ago | parent | prev [-]

I like how ZFS doesn’t have “bugs”, it has “defects”.