Re: [PATCH 00/13] overlay filesystem: request for inclusion (v16)

[J. R. Okajima]

Miklos Szeredi:
> Please consider overlayfs for inclusion into 3.10.

Thank you for CCing me.

First, I'd suggest you to follow some recent activities in mainline
kernel such as
- MODULE_ALIAS_FS
- file_inode()
- d_weak_revalidate() which may not be necessary for overlayfs as long
  as it prohibit users the direct-access to layers (bypassing
  overlayfs).


> It's included in Ubuntu and openSUSE, used by OpenWrt and various other
> projects.  I regularly get emails asking when it will be included in mainline.

Such situation is very similar which AUFS had a few years ago. At that
time, AUFS was rejected since UnionMount was chosen. Years passed, the
development of UnionMount seems to stop and linux mainline doesn't have
generic stackable filesytem yet. I had pointed out some defects in
overlayfs (and UnionMount too). They are all based upon the "name-based"
behaviour instead of "inode-based" one. Other than "Non-standard
behavior" in the overlayfs document, the are, for example,
- read(2) may get an 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).

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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/