Re: [PATCH 00/13] overlay filesystem v22

[J. R. Okajima]

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/