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

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

 



> > > What remains is ctime/mtime support.
> > >
> > > 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.
> >
> > Well, generic/503 which exercises these corners hangs
> > (503.dmesg attached)
>
> That was just a stupid bug in truncate (truncating ovl page with upper
> inode lock held -> ABBA deadlock).
>
> Attached the fix for that one.
>

Force pushed and re-tested.
Summary of regressions of "quick" xfstests since v5.0-rc1:

Wrong st_mtime/st_ctime:
generic/003 generic/080 generic/215

EIO on clone/dedupe:
generic/303 generic/304

Wrong st_blocks/fiemap:
generic/353 generic/392 generic/422

New lazy copy up semantics:
overlay/060

> > >
> > > And after that it needs to be optimized (->readpages() and
> > > ->writepages()), but I think that's the easy part.
> > >
> >
> > And we also need to flush pages on non direct IO cases
> > of ->writepages() and then we can revert:
> > e8d4bfe3a715 ovl: Sync upper dirty data when syncing overlayfs
> > and swoop the grand prize :)
>
> Yeah.
>
> I think the behavior should be tunable (ovl page cache vs. upper page
> cache), at least initially, so it can be benchmarked in various
> situations to see if there are no slowdowns with the new code.
>

Now the real fun begins... choosing the config option name ;-)

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