Messages in this thread | | | Date | Thu, 18 Feb 1999 16:23:07 -0500 | From | Raul Miller <> | Subject | Re: 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?
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.
I haven't thought a lot about tricks with mount (union filesystems, etc.) but I'm assuming that we're not going to allow stunts like mounting a file system in a subdirectory contained inside itself. So, you don't have to worry once you cross the mount point, even if the mount point has multiple identities -- hard links can't span filesystems.
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}.
> 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.]
-- 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/
| |