Alexander Viro <viro@math.psu.edu> wrote:
> Erm??? *Their* parents should come into dcache too.
Sure, the requirement is recursive till you get to the filesystem's root.
> > Note that I'm presuming that, within the filesystem, each directory must
> > have an internal unique id (perhaps block # -- if the file system doesn't
> > have inodes), and that the test you want to perform is: directory being
> > renamed is not in the set of {target directory, ancestors of target
> > directory in this same filesystem}.
>
> *All* ancestors, right? How would you recalculate this set on
> rename/rmdir/unlink? And besides, it's O(n^2) memory (n - number
> of inodes in the game) in the worst case, O(n*depth) in best.
I'm presuming that I could have a way of recognizing when I'm doing a
lookup on a directory that has already been examined, and that I can at
that point skip any further examination of the children of that directory.
I guess that means that I'd have to normalize each path to match the
way I'm pruning things.. which kinda trashes the idea of a cache.
Hmnm... bad.
> > > Now, assume that another lookup goes through the alternative path in the
> > > same time from the other direction. Your actions wrt locking?
> >
> > Use a per-filesystem directory rename lock when renaming a directory
> > and parallel parents are an issue. [I guess, to be safe, we'd have to
> > use the lock to determine if parallel parents are an issue.]
>
> Erm... You'll need to do it on any lookup.
Why? Maybe I'm getting into hot water here, but can't you just get
away with the existing "one dcache entry for the path you're looking
up" mechanism?
Or are you refering to the limitations of a normalization-for-comparison
scheme?
> Right now we lock the parent on each lookup step and release it before
> the next one. It is not rename-specific. Locking issues will become
> very tricky unless you are going to throttle lookups in the same way
> it is done with rename. I.e. single-threaded fs. Welcome back to
> Minix. Locking is used *not* only for rename/rename race prevention.
> Without it you'll get a race in about any pair of namespace-related
> operations.
Eh?
I can see that you need the rename lock for rename.
I can see that you need it to link directories.
I don't see that you need it for readdir.
I don't see that you need it for mkdir.
I don't see that you need it for stat.
I'm not sure whether you'd need it for rmdir.
I'm assuming that when you hold/release the rename lock that you're
not in the middle of a lookup, but that you can do lookups while you
hold that lock.
I guess this would throttle directory rename, but I don't see that this
would be a noticable effect. There's probably a way to not have to
throttle rmdir. No one cares if you throttle the creation of hard
links to directories [because "compared to what?"].
-- Raul- 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/