J. Bruce Fields [bfields@xxxxxxxxxxxx] wrote:
> On Fri, Jan 13, 2012 at 11:09:14AM -0600, Malahal Naineni wrote:
> > Trond Myklebust [Trond.Myklebust@xxxxxxxxxx] 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?
>
> Dumb question: remind me which filesystem your exporting that can't
> already generate stable filehandles?
Only answers can be dumb! Bruce, we have ext3/ext4 file systems on two
separate servers. The file systems are mirrored using rsync as and when
needed. We would like to use the servers as replicas.
Since the file systems are mirrored using "rsync", the NFS file handles
each server exports would be different. We would like to use volatile
file handles feature of NFSv4 for this.
Hope that helps.
Regards, Malahal.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
