Re: [PATCH v6 3/3] xfs: add support for FALLOC_FL_WRITE_ZEROES

On Thu, Jun 18, 2026 at 02:36:00AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 18, 2026 at 11:28:15AM +0200, Pankaj Raghav (Samsung) wrote:
> > > But I guess not unaligned FALLOC_FL_WRITE_ZEROES?
> > 
> >         -r readbdy: 4096 would make reads page aligned (default 1)
> >         -t truncbdy: 4096 would make truncates page aligned (default 1)
> >         -w writebdy: 4096 would make writes page aligned (default 1)
> > 
> > FALLOC_FL_WRITE_ZEROES comes under truncate. So I would assume we also
> > do that. That is how I also found the issue with offset > EOF. I will
> > take a look or else, I will add a test case to test this condition!
> 
> A targeted test using xfs_io that does FALLOC_FL_WRITE_ZEROES on an
> unaligned range and then checks that the data around it is preserved
> while the unaligned data in the range is zeroed would also be useful.
> 


|----------|----------|----------|----------|----------|
           ^     ^    ^                     ^     ^    ^
           |     |    |                     |     |    |
           |   offset |                     |    end   |
           |          |                     |          |
	off_rd       off_ru              end_rd       end_ru


I wrote a simple test case for unaligned FALLOC_FL_WRITE_ZEROES. The
existing code **does not** overwrite any user data. Here is why:

- xfs_free_file_space (punch hole) punches inward (offset_ru -> end_rd)
  and zeroes out from (offset -> offset_ru) and (end_rd -> end) with
  xfs_zero_range

- Luckily, even though we consider offset_rd to end_ru in
  alloc_file_space, XFS_BMAPI_ZERO will skip zeroing already written
  edge blocks and only offset_ru -> end_rd are zeroed using unmap zero range.
  ( (offset -> offset_ru) -> EXT_NORM, (offset_ru -> end_rd) -> HOLE,
  (end_rd -> end) -> EXT_NORM)

I didn't think it through but the code still holds for these cases. This
might be the reason why fsx did not complain? I will also document this
in the patch.

But as you said, we need a xfstest for this boundary block checks in case
some behaviour changes in the future.

I guess apart from this, the only change is to address persisting data
when offset > old_size as sashiko reported.

Let me know what you think.
--
Pankaj