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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
