lkml.org 
[lkml]   [1999]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: fsync on large files
Alexander Viro <viro@math.psu.edu> wrote:
> > > OK, so you are doing lookup on foo from /bar/baz. You see that foo is a
> ^^^^^^
> > > directory and it has another parent. You see that this parent is nowhere
> > > near dcache/icache. Worse yet, actually it's the end of *long* chain of
> > > directories and none of them (except the root, that is) is in dcache. To
> > > make it even nastier, suppose that there are fan-ins in that chain (i.e
> > > some of those directories also have multiple parents). Your actions?

On Thu, 18 Feb 1999, Raul Miller wrote:
> > Bring at least one instance of each parent into dcache. I don't think
> > this should be significantly worse than having a long path for the first
> > reference to a directory.

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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.268 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site