From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 References: <20190128192207.GA10240@redhat.com> In-Reply-To: From: Amir Goldstein Date: Tue, 12 Feb 2019 09:43:57 +0200 Message-ID: Subject: Re: [RFC][PATCH v2 0/5] Experiments with overlayfs filemap Content-Type: text/plain; charset="UTF-8" To: Miklos Szeredi Cc: Vivek Goyal , cgxu519 , overlayfs List-ID: > 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? 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. Thanks, Amir.