Messages in this thread | | | Date | Mon, 17 May 1999 14:07:24 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: VFAT rename |
| |
On Mon, 17 May 1999, H. Peter Anvin wrote:
> > So far I'm convinced that the only way to allow such renames is to > > change lookup() semantics for rename() target. It affects the whole > > fs/namei.c and fs/dcache.c, but at least it can be done. We already have > > races around lookup() and while they have no fs corruption potential now > > they *will* get it if we'll just go ahead and add a new flag for lookup, > > make vfat_lookup() keep the thing unhashed, etc. > > > > I'm sorry; I think we're talking about two different issues here. We > have established: > > 1. POSIX requirements don't apply here. > 2. The current VFS doesn't handle it correctly. > 3. This is necessary for reasonable behaviour. > > Conclusion: > > a. The VFS interface need to change. > > I don't see why this implies multiple dentries for a directory.
Because the whole idea of 'name' sits in dentry. Because after lookup() there is nothing other than said dentry. Because if we have the same dentry for Foo and fOO we have *no* distinction between them.
We can do the thing without changes in VFS/filesystems interface. I see how to do it. Sigh... Current situation with dcache is pretty odd - it's a half of very good thing. I.e. it gives *very* good separation between VFS and filesystems and can be turned into race-free namespace implementation. I've mostly massaged VFS/filesystems interface to the state when it can be done. But dcache still has a bunch of petty races and they may grow into the fs-corrupting ones with easy. It's very brittle. In fact VFAT managed to break it in a lot of subtle ways. What we really need is a design when races are dealt with in VFS. Completely. With no abuse of i_sem on directories. With the situation when filesystems don't have to think about interaction between methods. It can be done and I know how to do it. There is a couple of things to do before the thing will go (mostly with symlinks handling). I'll try to separate the namespace rewrite into gradual patches, but there will be several serious hops. So there...
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |