lkml.org 
[lkml]   [2007]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: If not readdir() then what?
    On Tuesday April 10, trond.myklebust@fys.uio.no wrote:
    > On Wed, 2007-04-11 at 07:37 +1000, Neil Brown wrote:
    > > On Tuesday April 10, trond.myklebust@fys.uio.no wrote:
    > > > On Wed, 2007-04-11 at 07:12 +1000, Neil Brown wrote:
    > > > >
    > > > > Is there something that makes that interface problematic?
    > > >
    > > > File deletions...
    > >
    > > How are they a problem ?
    > >
    > > There are only two ways to organise a directory.
    > > 1/ Unsorted linear list of entries in which no repacking is ever done.
    > > 2/ Some data structure using an ordered search key that is based on
    > > the filename (e.g. a B-tree with a search key that is a hash of the
    > > filename).
    > >
    > > In the first case, you just use a fixed opaque cookie for location in
    > > a directory.
    > > In the second you use the filename. If the file has been deleted,
    > > that shouldn't stop you finding the place where it would have been in
    > > the overall sort order.
    >
    > I beg to differ. RAMFS is an instance of a filesystem which uses an
    > unsorted linear list of entries which is automatically repacked when you
    > delete a file.

    hmm... yes...
    RAMFS uses dcache_readdir which keeps a cursor in the list of entries
    such that delete/insert doesn't change the effective location of the
    cursor.

    Doing that in NFS would require the server keeping an open file on
    behalf of the client. That wouldn't be too hard for NFSv4, except
    that you would still need some way to deal with server reboots.

    But then RAMFS wouldn't survive a server reboot anyway.

    >
    > You may also have filesystems which are only partially sorted. The
    > dcache is for instance organised as a hashtable with multiple entries
    > per bucket...

    That is like the filesystem Bob Copeland described.

    And if the chains are not sorted, then I think the only way you could
    reliably implement getdents is to use a cursor, and that doesn't map
    over NFS very well.

    Even if the chains were sorted, they could conceivably be sorted by
    position-in-file in which case my 'cookie or filename' would not be
    enough. You need 'cookie and filename'.

    So my new position is that:

    A READDIR (aka getdents2) should take a directory handle, a cookie,
    and a filename, and should return filenames and cookies. The
    cookies may all be identical or may not. The filename might be used
    by the filesystem, or it might not.

    Filesystems that require a cursor in the 'struct file' to support
    (local) getdents cannot be used with NFS.

    While it doesn't make it possible to support all conceivable
    filesystems, it should make it easier for some filesystems to support
    the demands of NFS.

    Thanks,
    NeilBrown
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-04-11 00:37    [W:1.185 / U:0.468 seconds]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean