Messages in this thread | | | From | "J. R. Okajima" <> | Subject | Re: [PATCH 0/7] overlay filesystem: request for inclusion | Date | Fri, 17 Jun 2011 00:15:02 +0900 |
| |
Erez Zadok: > (B) APPROACHES TO UNIONING ::: > My group, Juniro and his team, and I have spent a huge amount of time =
Oh, I have no team, no co-worker.
> over the years developing a standalone stackable file system based = > approach. These approaches were rejected largely due to their = ::: > location for this functionality. There is some merit to a VFS based = > approach: unioning performs a fair amount of namespace manipulation = > (merging directories, eliminating duplications, whiteouts and opaques, = > etc.), and the VFS is often best suited for complex namespace = > operations.
Exactly. I understand everybody likes simpler patch, and I have no objection to merge UnionMount into mainline. But this union-type-mount approach has some demerit which I have posted before. Those are inherited by overlayfs too, and Miklos called it "unPOSIXy behavior". I think the most part of the cause of these behaviour came from its design or architecture. At the same time, that is one reason I chose union-type-filesystem. In other words, there surely exists several issues which are hard to implement if we don't adopt union-type-filesystem (I never say it is impossible since someone else may get a new idea someday).
> (C) ABOUT OVERLAYFS > > I've reviewed overlayfs's code. I found it easy enough to follow that I = > was able to fix a few bugs and add a feature or two. It's small enough = > to be easily reviewed. I therefore argue that we should NOT try and add = > a ton of features to overlayfs now, but rather review it as is, consider = > merging it soon, and gradually add features over time (BTW, I just =
I agree that is one good way among several possible ways. But I think those missing features or "unPOSIXy behavior" are important and essentially necessary. For me, the current feature set of overlayfs looks like aufs many years ago when I started thinking about unioning. Aufs tried making those unPOSIXy behavior into correct behaviour for years and it was satisfied in the middle of aufs1 era. I don't know how next few years of overlayfs will be. It may be similar to the history of aufs, or totally different one. The priority of a feature to support direct-modification on a member is not so high. The correct behaviour is most important I think.
Additionally the number of members may be important too. Overlayfs supports only two members currently. When a user wants more layers, he has to mount another overlayfs over overlayfs. Since it is essentially equivalent to a recursive function call internally, and of course the stack size in kernel space is limited, I don't think it is good.
Also Miklos replied and said modifying the credentials internally does no harm to other threads. But I am still afraid it a security hole since the credentials is shared among threads. If I had time, I would test it by myself.
J. R. Okajima
| |