RE:(2) [PATCH 1/2] ext4: don't cache unzeroed blocks as written after a failed zeroout

[Daejun Park <daejun7.park@samsung.com>]

Hi Ojaswin,

On Thu, Oct 08, 2026 at 11:49:48 +0530, Ojaswin Mujoo wrote:
> Feel free to add:
>
> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
>
> btw, did you catch this with some fstests? If not I think it would be
> good to add a test for this.

Thanks for the review.

No, it wasn't fstests. I ran into it while working on 2/2: when adding
the fast commit tracking next to ext4_zeroout_es(), I checked what it
caches when the zeroout fails, and saw that zero_ex1/zero_ex2 keep their
length on that path. To confirm it, I put dm-error under the file system
and failed only the zeroout.

I turned that into an fstests case [2]. The existing dm-error tests
don't reach this path: they write with direct I/O, which leaves the
extent unwritten until the I/O completes, and so does a buffered write
with the default dioread_nolock.

v2 [1] keeps this patch unchanged, so I'll carry your tag if there is a
v3.

[1] https://lore.kernel.org/r/20261008-ext4-fc-zeroout-v2-0-55cab1e24fa3@samsung.com
[2] https://lore.kernel.org/r/20261008-ext4-zeroout-eio-test-v1-1-9bb66deaf646@samsung.com

Daejun