Re: [PULL for 3.18] overlay filesystem v24

From: J. R. Okajima
Date: Tue Sep 30 2014 - 01:03:56 EST

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:// 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
- unnecessary copy-up may happen, for example mmap(MAP_PRIVATE) after
- 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.

J. R. Okajima
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at