Re: [RFC][PATCH v2 0/5] Experiments with overlayfs filemap

Miklos Szeredi
2019-02-12T08:11:00Z

On Tue, Feb 12, 2019 at 8:44 AM Amir Goldstein <amir73il@gmail.com> wrote:
>
> > I think the only case where upper doesn't have direct IO support is
> > tmpfs. And in that case we should just turn off overlay pagecache by
> > default, since there's no upside to having a cache at the overlay
> > level. Same probably holds for DAX mounted filesystems as well.
> >
>
> Confused. Isn't overlay page cache the mechanism by which we
> plan to resolve MMAP_SHARED inconsistency.
> Do you propose that tmpfs/DAX won't be able to get MMAP_SHARED
> consistency, or am I missing something?

What I propose is making the default behavior be the most optimal (no
overlay pagecache for tmpfs or dax), but allow forcing overlay
pagecache on or off.

As you've said, the most important goodie to come from the overlay
pagecache is correct selection of inodes on syncfs. MAP_SHARED
consistency is more of a tickbox thing, IMO.

>
> This thread has been rolling for a while, so here is a recap of remaining
> issues:
>
> - Fix st_blocks failing tests
> - Synchronize page faults with truncate/fallocate?
> :Also fallocate/copyfile/reflink/etc will need some thought as we need
> :to not only flush out dirty pages, but in some cases prevent new
> :faults while the operation is in progress.
> - Optimization/performance
> :And after that it needs to be optimized (->readpages() and
> :->writepages()), but I think that's the easy part.
> - Truncate upper inode pages (post copyup and tail page write)
> - Make page cache opt-in and require direct_IO()
> - ovl_sync_fs()
>
> Did I miss anything?
>
> I will try to carve out some time to work on this during next cycle
> and/or chew at the TODO list occasionally, unless you get to it
> before I do. Let me know if you intend to work on this.

Okay.

Thanks,
Miklos