Re: NFS problems across reboot

[James Pearson <james-p@moving-picture.com>]

Having a quick look through the nfs-utils source, as a test, I changed
fendrmtabent() in nfs-utils-0.3.3/support/nfs/rmtab.c (used by mountd)
to:

void
fendrmtabent(FILE *fp)
{
        if (fp) {
                fflush(fp);
                fdatasync(fileno(fp));
                fclose(fp);
        }
}


which appears to help - I can reset my test server immediately after a
client mounts a disk - without getting the 'Permission denied' problems.

However, I have no idea if this is a 'sensible' thing to do ... if it is
OK to do this, would using fdatasync() elsewhere be helpful?

Thanks

James Pearson

James Pearson wrote:
> 
> I'm using XFS on my root file system - I'm using a "stock" RedHat 7.1 or
> 7.2 initscripts - so exportfs -r is run before rpc.mountd and rpc.nfsd
> 
> I can reproduce my problem by resetting an NFS server just after
> automounting one of its exported disks. When the server comes up, the
> client reports 'Permission denied' on that mount point.
> 
> If I repeat the test, but wait a short while before resetting the
> server, everything is OK on reboot - and rmtab contains an entry for the
> client).
> 
> It looks like the update to /var/lib/nfs/rmtab of the clients mount
> hasn't been sync'd to disk before the server is reset.
> 
> In fact I can simulate this on a running server and client by:
> 
> On the client, mount one of the server's exported file systems and cd to
> it.
> Runs 'ls', everything fine. Then:
> 
> On the server:
> 
> cd /var/lib/nfs
> cp rmtab rmtab.save
> cat /dev/null > rmtab
> /etc/init.d/nfs stop
> /etc/init.d/nfs start
> 
> Then on the client, attempt to 'ls' etc. gives 'Permission denied'
> 
> If I then copy back the saved rmtab file and restart nfs, file access on
> the client is OK.
> 
> I've also put /var/lib/nfs on an ext2 file system, but that didn't make
> any difference - it seems to be that fact that the 'crash' happens
> before the file data has been flushed to disk.
> 
> The man page for rpc.mountd says the rmtab file is 'mostly ornamental',
> however in this case, it seems to be a bit more important. ...
> 
> So, is it possible to have a client 'survive' a server crash even if its
> entry in rmtab hasn't been flushed? i.e. somehow allow the client access
> even if there is no entry for the client in rmtab?
> 
> Thanks
> 
> James Pearson
> 
> Neil Brown wrote:
> >
> > On Sunday April 7, neilb@cse.unsw.edu.au wrote:
> > >
> > > 13 == EACCES.  Looks like the filesystem isn't exported.
> > >
> > > Show us the relevent /etc/init.d file.
> > > My guess is that "exportfs -a" is being run *After* rpc.nfsd.
> > > It must must run *before* for correct operation.
> > >
> >
> > Actually, that would cause ESTALE, not EACCES.
> >
> > EACCES seems to suggest an XFS problem.
> > Can you duplicate this without using XFS????
> >
> > NeilBrown
> >
> > > NeilBrown
> > >
> > > _______________________________________________
> > > NFS maillist  -  NFS@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/nfs
> 
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs