> > 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/