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


    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/

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