Re: Strange SEEK_HOLE / SEEK_DATA behavior

[Matthew Wilcox <willy@infradead.org>]

On Mon, Oct 26, 2020 at 03:57:10PM +0100, Jan Kara wrote:
> Hello!
> 
> When reviewing Matthew's THP patches I've noticed one odd behavior which
> got copied from current iomap seek hole/data helpers. Currently we have:
> 
> # fallocate -l 4096 testfile
> # xfs_io -x -c "seek -h 0" testfile
> Whence	Result
> HOLE	0
> # dd if=testfile bs=4096 count=1 of=/dev/null
> # xfs_io -x -c "seek -h 0" testfile
> Whence	Result
> HOLE	4096
> 
> So once we read from an unwritten extent, the areas with cached pages
> suddently become treated as data. Later when pages get evicted, they become
> treated as holes again. Strictly speaking I wouldn't say this is a bug
> since nobody promises we won't treat holes as data but it looks weird.
> Shouldn't we treat clean pages over unwritten extents still as holes and
> only once the page becomes dirty treat is as data? What do other people
> think?

I think we actually discussed this recently.  Unless I misunderstood
one or both messages:

https://lore.kernel.org/linux-fsdevel/20201014223743.GD7391@dread.disaster.area/

I agree it's not great, but I'm not sure it's worth getting it "right"
by tracking whether a page contains only zeroes.

I have been vaguely thinking about optimising for read-mostly workloads
on sparse files by storing a magic entry that means "use the zero
page" in the page cache instead of a page, like DAX does (only better).
It hasn't risen to the top of my list yet.  Does anyone have a workload
that would benefit from it?

(I don't mean "can anybody construct one"; that's trivially possible.
I mean, do any customers care about the performance of that workload?)