Re: unusual behavior of loop dev with backing file in tmpfs

[Matthew Wilcox <willy@infradead.org>]

On Wed, Jan 12, 2022 at 09:19:37AM -0800, Darrick J. Wong wrote:
> I for one wouldn't mind if tmpfs no longer instantiated cache pages for
> a read from a hole -- it's a little strange, since most disk filesystems
> (well ok xfs and ext4, haven't checked the others) don't do that.
> Anyone who really wants a preallocated page should probably be using
> fallocate or something...

We don't allocate disk blocks, but we do allocate pages.

filemap_read()
  filemap_get_pages()
    page_cache_sync_readahead()
      page_cache_sync_ra()
        ondemand_readahead()
	  do_page_cache_ra()
	    page_cache_ra_unbounded()
	      __page_cache_alloc()
	      add_to_page_cache_lru()

At this point, we haven't called into the filesystem, so we don't
know that we're allocating pages for a hole.

Although tmpfs doesn't take this path; it has its own
shmem_file_read_iter() instead of calling filemap_read().  I do rather
regret that because it means that tmpfs doesn't take advantage of
readahead, which means that swapping back _in_ is rather slow.

It's on my list of things to look at ... eventually.