Re: [PATCH v3 2/2] exfat: EXFAT_IOC_GET_VALID_DATA ioctl

[David Timber]

On 3/12/26 12:23, Matthew Wilcox wrote:
> We already have two interfaces for this on Linux.  One is SEEK_HOLE /
> SEEK_DATA and the other is fiemap (Documentation/filesystems/fiemap.rst)
> Why are both of these interfaces unsuitable?
https://lore.kernel.org/linux-fsdevel/cf6c2b08-b7ff-4f70-95f4-cdb12ef5a666@xxxxxxxxxxxx/

Because exFAT is not a sparse file system. The VDL is only a shorthand
for fast cluster allocation without writing actual data to them. In
other words, the range between the VDL and isize is not actually a hole.
The blocks in the range are actually allocated, filled with garbage data
on the disk. The kernel has to be careful not to return it to userspace,
which is something Linux kernel actually does.

Suporting SEEK_DATA in exFAT will certainly give a wrong impression that
it is a sparse fs. On the other hand, FALLOC_FL_PUNCH_HOLE on an
arbitrary range(other than docking to EOF) is not possible. Therefore,
it wouldn't make sense if a fs could do SEEK_HOLE, but not punch holes.
That would most likely confuse many userland programs like cp. That's
why I thought lseek() is not a good fit for querying VDL.

Truncating up a file in sparse file systems does not change st_blksize,
but exFAT does. I have to say this is rather an unfortunate digergence,
certainly not POSIX compliant, but the behaviour existed for a long time
now and no one is coming forward to say that something caught on fire yet.

I don't understand why people keep bringing up FIEMAP. It is a debugging
interface and it should stay that way. It's simply not the right tool to
find holes in files. SEEK_DATA and SEEK_HOLE became POSIX, so using
FIEMAP to find holes and data shouldn't even be an option at this point.

Davo