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

[Ojaswin Mujoo]

On Thu, Oct 08, 2026 at 04:47:14PM +0900, Daejun Park wrote:
> Hi Ojaswin,
> 
> On Thu, Oct 08, 2026 at 11:49:48 +0530, Ojaswin Mujoo wrote:
> > Feel free to add:
> >
> > Reviewed-by: Ojaswin Mujoo <ojaswin@xxxxxxxxxxxxx>
> >
> > 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.

Yeah, its a bit tricky to hit this in kunit test cause it needs one
zeroout to pass and one to fail, so good to have a test for this case.
Thanks for sending that, I'll take a look!
> 
> 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.

Ohh, i missed the v2, I'll send it there as well no worries.
> 
> [1] https://lore.kernel.org/r/20261008-ext4-fc-zeroout-v2-0-55cab1e24fa3@xxxxxxxxxxx
> [2] https://lore.kernel.org/r/20261008-ext4-zeroout-eio-test-v1-1-9bb66deaf646@xxxxxxxxxxx
> 
> Daejun