Re: [PATCH 00/13] overlay filesystem v22

From: J. R. Okajima
Date: Sun May 25 2014 - 21:57:02 EST



Thanks for CC-ing me.

Here are some comments.

- I have no objection about the 0:0 char-dev whiteout, but you don't
have to have the inode for each whiteout. The hardlink is better.
In this version, you have <workdir> now. How about creating a "base"
whiteout under workdir at the mount-time? Maybe it is possible by
user-space "mount.overlayfs" or kernel-space. When the whiteout meets
EMLINK, create a non-hardlink for that target synchronously and
re-create the "base" asynchronously.

- Is <workdir>/work always visible to users? If a user accidentally
removes it or its children, then some operations will fail. And he
cannot recover it anymore. I know it cannot easily happen since its
mode is 0. But I am afraid it will be a source of troubles. For
example, find(1) or "ls -R /overlayfs" will almost always fail.

- If I remember correctly, the length of the dir mutex is held time has
been pointed out. This version has still a long mutex held time, a whole
copy-up operation includeing lookup, create, copy filedata, copy
xattr/attr, and then rename. How about unlock the dir before copying
filedata and re-lock and confirm after copying attr?

- When two processes copy-up a similar dir hierarcy, for example
/dirA/dirB/fileC and /dirA/dirB/dirC/fileD, may a race condition
happen? Two processes begin copying-up dirA, first processA succeeds
it and second processB fails and returns EIO?

- All copy-up operations will be serialized due to <workdir> lock.

- In fstat(2) for a dir, is nlink set to 1 even it is removed?

- In readdir, it lookup or getattr to determine whether the found char
dev entry is a whiteout or not. I know a char dev is not so many, so
this overhead won't be large. But if its name represented "I am a
whiteout", then the extra lookup or getattr would be unnecessary.


My personal impression for overall is overlayfs starts growing.
Also several parts look like towarding aufs. For example,
- a <workdir> means an overlayfs specific work. Aufs has such special
dir for copying-up an unlinked file and a pseudo-link. Both are
unnecessary for overlayfs because overlayfs copies-up a file in
open(2) time, and doesn't support the hardlink between layers.
- many small wrapper functions for VFS helpers resemble to aufs
too. In aufs, all they have lockdep_off/on.
- the internal cache for readdir allocating extra memory. Aufs adopts
a simple hashing, while overlayfs uses rbtree.

But of course the fundamental design differences between overlayfs and
aufs are kept, such as
- a name-based union .vs. an inode-aware union
- multiple layers
- allow users to access the layers directly
- etc...

If LKML people consider merging overlayfs, then I'd ask to consier aufs
too. The basic design is unchanged since when I posted a few years ago.
http://marc.info/?l=linux-kernel&m=123934927611907&w=2

And latest one is
http://aufs.sourceforge.net


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/