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

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

 



> 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.



[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