[lkml]   [1997]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: pre-patch2.1.45-3 lookin' good

    On Sun, 13 Jul 1997, Bill Hawes wrote:
    > I guess my view is very "inode-centric", but I think the above approach
    > would work well with waht we've got, and could be implemented to be 100%
    > free of races.

    You're probably right. However, we'd need to move to a dentry-centric
    world-view eventually in any case: the current inode-based stuff doesn't
    work too well if we want to get full advantage of the things that the
    dentries offer us.

    For example, thanks to the dentry model we should actually be able to do
    loopback mounts with no extra cost. Loopback mounts are essentially "hard
    linked directories", but with the added caveat that ".." for the
    hardlinked directory points back _both_ ways (depending on how you got to
    the point).

    Loopback mounts used to be pretty much impossible to do before - I had
    thought about it and the only way to do them reliably would be to
    essentially alias all the inodes that you traverse in the looped back
    mount. However, with dentries the loopback problem essentially goes away:
    we don't need to alias the inode at all, and the dentry ".." following
    automatically gives us what we want.

    However, there is one ugly exception: "fchdir()". For fchdir() to work
    correctly we must have the correct _dentry_ in the "struct file", not just
    the inode - because if we have the inode in the struct file, then we
    cannot distinguish between different loopback mounts..

    Also, as the dentries give us full pathname information, we're going to
    start using it. But if we want to get the path-name of any open file in
    the filesystem we again need the _dentry_ to the file, not the inode,
    because otherwise we cannot distinguish between two pathnames that share
    the same inode (normal hard links).

    The full path name information is very cool: we can do a "getcwd()" system
    call that is going to be a few orders of magnitude faster than the
    traditional way of doing "getcwd()".


     \ /
      Last update: 2005-03-22 13:39    [W:0.052 / U:21.452 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site