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:

quoted

quoted

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