Bug#148482: 'nfs-kernel-server reload' immediately stales all nfs handles

Bug#148482: 'nfs-kernel-server reload' immediately stales all nfs handles

[Chip Salzenberg]

So is 'exportfs -r' *supposed* to stale all NFS handles?  If so, is this
adequately documented?  adTHANKSvance

----- Forwarded message from Herbert Xu <herbert@gondor.apana.org.au> -----

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.  -        <chip@pobox.com>
         "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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Bug#148482: 'nfs-kernel-server reload' immediately stales all nfs handles

[Neil Brown]

On Sunday September 15, chip@pobox.com 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs