Messages in this thread | | | Date | Thu, 18 Feb 1999 17:07:26 -0500 (EST) | From | Alexander Viro <> | Subject | Re: fsync on large files |
| |
On Thu, 18 Feb 1999, Raul Miller wrote:
> 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? > > 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. Erm??? *Their* parents should come into dcache too.
> 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.
> > 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. 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.
- 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/
| |