On Tue, Sep 30, 2014 at 6:54 AM, J. R. Okajima <hooanon05g@xxxxxxxxx> wrote: > > David Howells: >> Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> >> > I'd like to propose overlayfs for inclusion into 3.18. >> > >> > Al, would you mind giving it a review? >> > >> > Git tree is here: >> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs.current >> >> Tested-by: David Howells <dhowells@xxxxxxxxxx> > > Does it mean overlayfs passed all your unionmount-testsuite? And does > the test suite contain tests for "inode-based" union? For example, > - read(2) may get the obsoleted filedata (fstat(2) for metadata too). > - fcntl(F_SETLK) may be broken by copy-up. > - inotify may not work when it refers to the file before being > copied-up. > - unnecessary copy-up may happen, for example mmap(MAP_PRIVATE) after > open(O_RDWR). > - exporting via NFS and fhandle systemcalls will not work. Most of this is explicitly documented. > > A few releases ago, OFD file-lock was introduced to improve the > behaviour of POSIX lock. POSIX lock has made users confused and I am > afraid that the similar story will come up because of the "name-based" > union behaviour. Of course the story is not limited to the file-lock. > > If I remember correctly, are you the one who consitunes the development > of UnionMount? Is the development totally stopped? > Next paragraph is what I wrote several times. > AUFS is an "inode-based" stackable filesystem and solved them many years > ago. But I have to admit that AUFS is big. Yes it is grown up. > I don't stop including overlayfs into mainline, but if the development > of UnionMount is really stopped, then I'd ask people to consider merging > aufs as well as overlayfs. Union-mounts are namespace based as well. There's little semantic difference between overlayfs and union-mounts. The difference is mostly in the implementation. It would be good to have an inode based union as well. I suggest (as I suggested many times) to try slimming aufs to a bare minimum and submit that. It may be easier to just start from scratch instead trying to drop features from the existing codebase. I'd be happy to review and generally help with such an effort. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
