Messages in this thread | | | Date | Sun, 29 Aug 2004 19:31:49 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: silent semantic changes with reiser4 |
| |
On Sun, 29 Aug 2004, Trond Myklebust wrote: > > Well, yes there has to be a distinction between a true bind mount which > actually covers the file or directory, and something like the stream > "bind mount" which doesn't. > > The stream "bind mount" is just there to allow you to root the > attributes in a single tree. It can be made functionally entirely > equivalent to the openat(), but uses pathname semantics (e.g., "//") to > denote the attribute fork instead of an extra function call.
Using '//' would be nice, but would break real apps. If I remember correctly, POSIX specifies that '//' can be special at the _beginning_ of a path, but in the middle, it has to act like a single '/'.
And that's not just theory - it's quite common for programs to just concatenate a directory name (which may or may not end with a slash) with another path-name that starts with a slash. So you _will_ see existing scripts and programs using things like "/usr/include//sys/type.h", and they'd break if "//" would switch from "regular namespace" to "attribute namespace".
So I don't see any way to extend pathname semantics to distinguish between "directory contents" and "directory attribute stream".
> > It's easy enough to do the graph detection at the VFS layer, exactly > > because of the density of the dentry graph. > > Don't you end up having to lock the entire paths b/c/d and a/e/f in > order to prevent "ln a b/c/d/a; ln b a/e/f/b"?
That's not the problem - since it's in memory, we can just get the dcache lock, and do it locked for t least local filesystems.
However, being prodded by Andries, I think I'm wrong _anyway_. Since the dcache is only "dense" down one path to the root, and doesn't contain all the alternate ways of getting to a particular directory, I came to the conclusion that the VFS layer can't actually do cyclic detection after all...
So together with the fact that nobody really _wants_ hardlinks to directories, I think the right answer is "no". It's not a problem as long as the attributes streams are always tied to the file/directory they are attributes of - then the "directory link" is really just a file link, and can't cause any cycles.
> > - how to actually test this out in practice (ie getting reiser4 to do the > > proper thing wrt the VFS layer, but preferably _also_ having another > > filesystem like NFSv4 or cifs that actually uses this and shows what > > the problems are). > > As I said, NFSv4 can be made ready pretty quickly: Bruce is already > finishing up the xattr implementation.
Do we have any servers that implement it? I think NFSv4 might be a good test-case if so.
> > - whether it makes any sense at all unless we also make at least a few > > other filesystems support it, so that people start using it as an > > "expected feature" rather than a "works only on a couple of machines". > > NTFS? ;-)
Hey, I see the smiley, but I'd still like to point out that not many people use it under Linux, and while I think writing to it might be stable these days, I don't believe named streams are necessarily going to materialize all that quickly..
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |