From: James Pearson <james-p@moving-picture.com>
To: Neil Brown <neilb@cse.unsw.edu.au>
Cc: David Ford <david+cert@blue-labs.org>, nfs@lists.sourceforge.net
Subject: Re: NFS problems across reboot
Date: Mon, 08 Apr 2002 14:42:47 +0100 [thread overview]
Message-ID: <3CB19E57.EB3F1441@moving-picture.com> (raw)
In-Reply-To: 15535.56536.237108.198660@notabene.cse.unsw.edu.au
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
next prev parent reply other threads:[~2002-04-08 13:48 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-04 19:27 NFS problems across reboot David Ford
2002-04-05 9:12 ` James Pearson
2002-04-07 4:43 ` David Ford
2002-04-07 5:23 ` Neil Brown
2002-04-07 5:44 ` Neil Brown
2002-04-07 6:48 ` David Ford
2002-04-08 13:42 ` James Pearson [this message]
2002-04-08 15:23 ` James Pearson
2002-04-08 23:10 ` Neil Brown
2002-04-07 6:39 ` Daniel Freedman
2002-04-08 2:50 ` Neil Brown
2002-04-07 6:59 ` David Ford
2002-04-08 2:48 ` Neil Brown
2002-04-08 12:15 ` Andreas Unterluggauer
2002-04-08 22:58 ` Neil Brown
[not found] <E16uI1v-00067H-00@usw-sf-list1.sourceforge.net>
2002-04-08 0:43 ` Al Borchers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CB19E57.EB3F1441@moving-picture.com \
--to=james-p@moving-picture.com \
--cc=david+cert@blue-labs.org \
--cc=neilb@cse.unsw.edu.au \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.