Messages in this thread |  | | From | Miklos Szeredi <> | Subject | Re: [PATCH 0/7] overlay filesystem: request for inclusion | Date | Thu, 16 Jun 2011 18:09:02 +0200 |
| |
"J. R. Okajima" <hooanon05@yahoo.co.jp> writes:
>> 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.
Yes, overlayfs shares some of the basic architecture of union-mounts. The most important such property is that when a file is copied up, it's like replacing the file with a new one:
cp /foo/bar /tmp/ttt mv -f /tmp/ttt /foo/bar
Which is exactly the thing that some editors do when saving a modified file, so most applications should handle this behavior fine. The truth is a bit more complicated and the effect of the copy-up is more like this:
cp /foo/bar /tmp/ttt mount --bind /tmp/ttt /foo/bar
> 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.
Good point about stack space.
Adding multiple read-only layers should be really easy, and could be one of the first extensions after the merge.
> 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.
The credentials of the current task are not modified but replaced by new, temporary credentials. This will only have an affect on a single thread.
Thanks, Miklos
|  |