Re: [PATCH/RFC 0/7] Volatile Filehandle Client-side Support

[Malahal Naineni <malahal@us.ibm.com>]

Trond Myklebust [Trond.Myklebust@netapp.com] wrote:
> On Mon, 2011-11-14 at 08:07 +1100, NeilBrown wrote:
> 
> > If a server has objects that are never renamed, it can easily use volatile
> > file handles.
> > If a server has objects which can be renamed and wants to use volatile file
> > handles, then if such an object is open and is about to be renamed, it must
> > first log to stable storage some mapping to allow it to access the file from
> > the old volatile file handle.  And of course it cannot allow renames during
> > the grace period, but I think we already have that.
> > Also, if the VFH is such that it will be  lost on a reboot, the server must
> > log it to stable storage before allowing an open.
> 
> BTW: If the namespace is stable, then the server can easily implement
> permanent filehandles. Use a hash of the pathname as the filehandle, and
> set up a hidden directory ('/.filehandles') containing symlinks that map
> said hash back to the correct pathname. No need for volatile
> filehandles.

Neil and Trond, one of our use cases is for a read only file system. The
name space is stable and Volatile File Handle support should not have
any issues under those conditions, correct?

Trond, trying to understand how we can make file handles permanent at
the servers with your ideas. We do use linux NFS server. Looks like the
server needs a new config parameter to hide '/.filehandles' and use it
for storing permanent file handles. Also, the solution needs a tool
that generates/populates './filehandles' directory. I don't know how
best we should handle hash collisions at this point (shouldn't be an
issue once we agree to a method though). Anything else I am missing?

Any thoughts from linux NFS server community? Is this approach
acceptable?

Regards, Malahal.