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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > > I'll stick with the simple copy_page() implementation (back and forth)
> > > unless you come up with a better suggestion. We will probably want
> > > something more efficient later on, but I rather start with something
> > > simple and working.
> > >
> >
> > Like this:
> > https://github.com/amir73il/linux/commits/ovl-aops-wip
> >
>
> Am I understanding it right, that we will use page cache at overlay inode
> as well as upper file system. So there is duplication and memory usage
> for upper files will double?

That won't be acceptable, but using upper page cache as temporary pages
for the duration of writeback makes overlayfs code much simpler IMO and
avoids vma -> vfs locking order issues.

My idea was to get rid of the upper pages once writeback is done
(or periodically), but that wasn't implemented yet, because I am still
waiting to hear if the idea is inherently bad.

Think of upper inode page cache as a storage device cache.
Filesystem writes to storage device cache (not to media) and cache
is flushed to media on explicit from filesystem or periodically.

Once overlay pages have been copied to upper page cache, they
are "clean" and can be reclaimed at any time, even before upper
inode writeback has completed.

> If yes, this will be reason to provide
> separate option for lazy copy up (Or switch to using O_DIRECT).
>

Although I started this series with lazy copy up, it is lazy copy up that
depends on overlay aops and not the other way around.
The plan (as Miklos depicted it) is to use overlay page cache for copied
up file (UPPER_SHARED) as well as for lower files that were open
for write or mmap shared (LOWER_SHARED).

Lazy copy up is just a very simple stepping stone on the way there,
because it demonstrates that we can defer the decision of switching
from LOWER state (no page cache) to LOWER_SHARED until mmap
time and the decision to switch to UPPER_SHARED state (copy up data)
until the first page fault (later it will be on writable page fault).

In the end, "lazy copy up" will mean no copy up at all on open and it will
not depend on metacopy. There is also no expected reason why users
would need to opt-out of overlay page cache that solves shared mmap
inconsistency and improved efficiency of syncfs.

Thanks,
Amir.



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux