<story><title>A data corruption bug in OpenZFS?</title><url>https://despairlabs.com/blog/posts/2023-12-25-openzfs-data-corruption-bug/</url></story><parent_chain></parent_chain><comment><author>cesarb</author><text>IMO, part of the issue is that something which used to be just a low-level optimization (don&amp;#x27;t store large sequences of zeros) became visible to userspace (SEEK_HOLE and friends). Quoting from this article:&lt;p&gt;&amp;quot;This is allowed; its always safe to say there’s data where there’s a hole, because reading a hole area will always find “zeroes”, which is valid data.&amp;quot;&lt;p&gt;But I recall reading elsewhere a discussion about some userspace program which did depend on holes being present in the filesystem as actual holes (visible to SEEK_HOLE and so on) and not as runs of zeros.&lt;p&gt;Combined with the holes being restricted to specific alignments and sizes, this means that the underlying &amp;quot;sequence of fixed-size blocks&amp;quot; implementation is leaking too much over the abstract &amp;quot;stream of bytes&amp;quot; representation we&amp;#x27;re more used to. Perhaps it might be time to rethink our filesystem abstractions?</text></comment>
<story><title>A data corruption bug in OpenZFS?</title><url>https://despairlabs.com/blog/posts/2023-12-25-openzfs-data-corruption-bug/</url></story><parent_chain></parent_chain><comment><author>dannyw</author><text>Fascinating write up. As someone with a ZFS system, how can I check if I’m affected?</text></comment>