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

[Matthew Wilcox <willy@infradead.org>]

On Thu, Mar 12, 2026 at 11:02:29PM +0900, David Timber wrote:
> 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@dev.snart.me/
> 
> 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.

Uh, no it's not.  If you try to read from the file at positions mapped
to those blocks, Linux will return zeroes.

You seem to be under the impression that SEEK_HOLE only finds blocks
which have not been allocated.  That's not the behaviour of any
filesystem whch uses iomap.  Look:

static int iomap_seek_hole_iter(struct iomap_iter *iter,
                loff_t *hole_pos)
{
        loff_t length = iomap_length(iter);

        switch (iter->iomap.type) {
        case IOMAP_UNWRITTEN:
                *hole_pos = mapping_seek_hole_data(iter->inode->i_mapping,
                                iter->pos, iter->pos + length, SEEK_HOLE);
                if (*hole_pos == iter->pos + length)
                        return iomap_iter_advance(iter, length);
                return 0;
        case IOMAP_HOLE:
                *hole_pos = iter->pos;
                return 0;

Yes, if there's literally a hole, that counts as a hole, but what you're
talking about is an unwritten extent.  And that counts as a hole
*unless* we've written to the page cache covering the hole.