So is 'exportfs -r' *supposed* to stale all NFS handles? If so, is this
adequately documented? adTHANKSvance
----- Forwarded message from Herbert Xu <[email protected]> -----
Package: kernel
Version: N/A; reported 2002-05-29
Severity: grave
Justification: causes non-serious data loss
While diagnosing an autofs problem with a particular client, I wanted to reload
changes to the /etc/exports file into the kernel nfs server. I ran:
/etc/init.d/nfs-kernel-server reload
which basically runs the command:
exportfs -r
The man page for this command does not indicate this is a destructive action
and I know I have run this same command on previous versions of the kernel with
no problems.
The result this time was that every client with automounted home directories
immediately got stale file handles which caused them to lose access to their
running apps. We had to go to each client to manually restart autofs on each
client to restore the nfs file handles. Unfortunately, many people lost the
files they were working on.
----- End forwarded message -----
--
Chip Salzenberg - a.k.a. - <[email protected]>
"It furthers one to have somewhere to go."
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sunday September 15, [email protected] wrote:
> So is 'exportfs -r' *supposed* to stale all NFS handles? If so, is this
> adequately documented? adTHANKSvance
exportfs -r
is very dependant on the contents of /var/lib/nfs/rmtab.
Any export that exportfs finds in /proc/fs/nfs/exports that cannot be
deduced from /var/lib/nfs/rmtab and /etc/exports will be removed.
We try to keep rmtab up-to-date correctly, but the MOUNT protocol
really isn't good enough to get it 100% right.
My guess is that for some reason, some of the clients were not listed
in rmtab, so their entries in /proc/fs/nfs/exports were removed.
I don't know what would have caused this. It could have been an admin
error. It could be that the automounter sends unmount messages at the
wrong time.
It is possible that 'nfs-kernel-server reload' should do "-a", not
"-r", but it isn't certain.
The most obvious difference between the two is shown by this example:
I have some standard exports in /etc/exports and I run
exportfs -a
to enact them.
I then want to do another export for some special, temporary purpose,
so I
exportfs -o no_root_squash,rw mydesktop:/usr/src
Later I make some changes to /etc/exports and want to enact them.
If I
exportfs -a
then it will enact those changes, and leave my temporary export in
place.
If I
exportfs -r
then it will enact those changes and remove my temporary export.
Which is right? In different situations you want different
behaviour.
Maybe:
reload -> exportfs -a
enforce -> exportfs -r
Locally, we have a policy (and machinery) that says that any temporary
change will probably be blown away over night, so it you want
something to be more permanent than that, to it 'properly'. So for
us, a nightly "exportfs -r" would probably be appropriate... as long
as our automounters did the right thing...
Again, 2.6 should not have the same dependance of rmtab so in a couple
of years you shouldn't have to worry.
NeilBrown
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs