lkml.org 
[lkml]   [2009]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 16/20] ceph: nfs re-export support
    From
    On Thu, Jul 16, 2009 at 03:07:35PM -0700, Sage Weil wrote:
    > On Thu, 16 Jul 2009, Trond Myklebust wrote:
    > > On Thu, 2009-07-16 at 12:50 -0700, Sage Weil wrote:
    > > > On Thu, 16 Jul 2009, J. Bruce Fields wrote:
    > > > > On Wed, Jul 15, 2009 at 02:24:46PM -0700, Sage Weil wrote:
    > > > > > Basic NFS re-export support is included. This mostly works. However,
    > > > > > Ceph's MDS design precludes the ability to generate a (small)
    > > > > > filehandle that will be valid forever, so this is of limited utility.
    > > > >
    > > > > Is there any hope of fixing that?
    > > >
    > > > Yes, but it requires some additional ondisk metadata the MDS isn't
    > > > maintaining yet (a parent directory backpointer on file objects).
    > > >
    > > > The MDS changes will mean more random IO for rename intensive workloads,
    > > > but the backpointers would also be useful for rebuilding the directory
    > > > tree in the event of some catastrophic metadata loss or corruption.
    > > > (Currently they're only there for directories, not all files.)
    > >
    > > Note that a filehandle that contains parent directory information is
    > > still not one that is valid forever. It will change in the case of a
    > > cross-directory rename, and so isn't a filehandle in the NFSv2/v3 sense.
    > > Even in the NFSv4 case, it would have to be labelled as 'volatile'.
    >
    > Right. The parent directory information in the fh it used as a hint, but
    > can't be relied on because of the rename problem. That's exactly why the
    > Ceph MDS will need to be changed to maintain backpointers on all files,
    > not just directories. When that happens, reexporting via NFS will work
    > reliably. Until then, old and idle filehandles for renamed files will
    > eventually go stale.

    Maybe I should look again at the patch instead of continuing to ask,
    but.... I'm confused: how will having a backpointers from inodes to
    directories help do the filehandle-to-inode lookup? (If you can't look
    up the inode in the first place, what use is any pointer stored in that
    inode?)

    --b.


    \
     
     \ /
      Last update: 2009-07-17 16:07    [W:0.022 / U:29.928 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site