nfsv4 server patches and status

[William A. (Andy) Adamson]

On 7/11/07, Trond Myklebust <trond.myklebust at fys.uio.no> wrote:
>
> On Wed, 2007-07-11 at 23:59 +1000, Neil Brown wrote:
> > On Wednesday July 11, jlayton at redhat.com wrote:
> > >
> > > C) have some sort of munging of the filehandle by the server so
> > > filehandles are likely to change between reboots
> >
> > C wins.  The filehandles generated for tmpfs contain a timestamp of
> > then the file was created (see setting and usage of i_generation in
> > mm/shmem.c).  So it is very unlikely that filehandles will very be
> > reused (this was a deliberate design goal) even over a reboot.
> >
> > It could still be confusing for the client if a mountpoint suddenly
> > has to change filehandle/inumber as would happen at reboot.
> >
> > That could be a good argument for not using a tmpfs filesystem...
>
> No. I don't buy that argument.
>
> For one thing, clients should not normally be mounting the pseudofs: the
> latter exists in order to bridge the gap between typical NFSv2/v3 setups
> which export the directories '/foo' and '/bar', but not '/'.
> A client that mounts the pseudo-fs node '/' will certainly not be able
> to fall back to a NFSv2/v3 mount if the NFSv4 server goes down.


Why would the NFSv2/3 server be working if the NFSv4 server is down? Aren't
they usually the same serivce?
I expect mounting "/" of the top server will be common as the NFSv4
namespace becomes used. Referrals will also most likely point to "/" of
another server. So I think clients will normally be mounting the pseudofs.

-->Andy

Secondly, we can add recovery code for this kind of temporary
> filehandles. I'm going to have to do so in order to deal with filesystem
> migration events anyway.
>
> Trond
>
> _______________________________________________
> NFSv4 mailing list
> NFSv4 at linux-nfs.org
> http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/nfsv4/attachments/20070711/863e4efe/attachment.html