Re: Delays on "first" access to a NFS mount

[Neil Brown <neilb@suse.de>]

On Wednesday March 7, bfields@fieldses.org wrote:
> On Thu, Mar 08, 2007 at 09:37:18AM +1100, Neil Brown wrote:
> > On Wednesday March 7, bfields@fieldses.org wrote:
> > > 
> > > Well, non-head-hurty ideas always welcomed.  I've got two export-related
> > > problems to fix:
> > > 
> > > 	- Our current NFSv4 pseudofs fsid=0 hack is a pain to administer
> > > 	  and results in inconsistent paths across different NFS
> > > 	  versions.
> > 
> > You've got to put that v4 pseudo root somewhere...
> > It just needs cleverness in nfs-utils to auto-bind-mount things into
> > the pseudoroot...
> 
> I've got make-mountd-clever patches here; if I can get them working in
> the next couple days then I'll pass them along so people can see what
> they're doing.

Cool.

> 
> > but I guess people cannot magically unmount things then.
> >
> > How about this.  We add an export option "follow-symlinks" so that
> > when nfsd is asked to stat a symlink it does a 'stat' instead of an
> > 'lstat' (effectively).
> > Then we get mountd to make a tmpfs in /var/lib/nfs/pseudoroot which
> > contains directories and symlinks to the various export points names
> > in etab.  This tmpfs is exported as fsid=0,follow-symlinks.
> > 
> > Problem solved?
> 
> Maybe.  Getting those symlink/mountpoints right sounds tricky.

Is it?
 mount -t tmpfs tmpfs /var/lib/nfs/pseudoroot
 grep '^/' /etc/exports | while read a b
 do
   d=`dirname $a`
   mkdir -p /var/lib/nfs/pseudoroot/$d
   ln -s $a /var/lib/nfs/pseudoroot/$a
 done
(untested, and probably has some corner cases but the essence is
 there).


> 
> How different is this from the in-kernel automounting that the NFS
> client is using for fsid traversal, for example?
> 
> > Ofcourse if different clients get to see different exports, then we
> > might need multiple tmpfs's in /var/lib/nfs/pseudoroot/$CLIENT/ ....
> 
> Ugh.  Is this something a lot of people do?

Well, if you export a different root filesystem to each diskless
client, or if you export /home to some places and /backup to others,
then you already have the potential for a different pseudo filesystem
for each client.  My little hacky shell script above essentially
merges them all which might be OK, or might not.

Suppose you wanted to allow every diskless client to see it's root as
'/'?  Is that a dumb thing to do, or just a difficult thing to do?

I was just looking at the RFC again and saw this in section 7.3:

   Based on the construction of the server's name space, it is possible
   that multiple pseudo filesystems may exist.  For example,

   /a         pseudo filesystem
   /a/b       real filesystem
   /a/b/c     pseudo filesystem
   /a/b/c/d   real filesystem

   Each of the pseudo filesystems are considered separate entities and
   therefore will have a unique fsid.

That adds a whole new dimension of complexity..... do we really want
to go there?

NeilBrown

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs