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. 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. http://aufs.sf.net J. R. Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
