Re: State of NFSv4 VolatileFilehandles

["J. Bruce Fields" <bfields@fieldses.org>]

On Fri, Aug 05, 2011 at 09:38:33AM -0400, Christoph Hellwig wrote:
> On Thu, Aug 04, 2011 at 12:03:44PM -0400, J. Bruce Fields wrote:
> > The client has no way of knowing that an export is read only.  (Or that
> > the server guarantees the safety of looking up names again in the more
> > general cases Neil describes.)  Unless we decide that a server is making
> > an implicit guarantee of that just by exposing volatile filehandles at
> > all.  Doesn't sound like the existing spec really says that, though.
> > 
> > If an examination of existing implementations and/or some sort of new
> > spec language could reassure us that servers will only ever expose
> > volatile filehandles when it's safe to do so, then maybe it would make
> > sense for the client to implement volatile filehandle recovery?
> > 
> > But if there's a chance of "unsafe" servers out there, then it would
> > seem like a trap for the unwary user....
> > 
> > Your rootfs's probably aren't terribly large--could you copy around
> > compressed block-level images instead of doing rsync?
> 
> Another scheme is to disconnect the file handles from the inode number.
> I implemented this a couple years ago for a customer.  Basically add
> an extended attribute into each inode that contains the nfs file handle,
> and that handle stays the same independent of the inode number.  The
> added complexity is that you need a new lookup data structure mapping

And that data structure should be persistent--how were you storing it?

> from your nfs handle to something that can be used to find the inode
> (inode number typically).

Interesting, I've wondered before how well that would work.  Any lessons
learned?

--b.