Bug 1125039

Sounds like there may be a bug, but:  I don't understand why you were trying to mount after the reboot?

When the server reboots while the clients are active, clients shouldn't have to do anything; just wait for the reboot (plus another 90 seconds for the NFSv4 grace period) and normal operation should resume.

What exactly was the sequence of events here, with about how much time between each step?

couple of things:
the filesystem is huge, 20TB, btrfs and takes a long time to mount on the nfsserver -- not sure why this is. I may switch back to xfs, seemed more stable under nfs.

order of this issue:
1) reboot nfsserver after yum update -y.
2) nfsserver slow booting waiting on mount, as above.
3) log in to clients and issue 'mount -a' and the mount times out.
   on some clients, both fedora and non-fedora, the nfs mount comes back as you said without a 'mount -a' needed.
4) issue the exportfs -a -f -r .
5) the problem clients 'mount -a' happens in less then a second.

caveat:
the clients that have the problem have been 'fedup' for quite a few releases, god bless me! the fedora client that works as you said, has had less upgrades and newer MB/CPU/etc, its *not* fedup free...I know fedup can be suspect.

forgot to say that i only tried the 'mount -a' on the clients *after* a clean mount on the nfsserver. g.)

I doubt fedup is an issue, but the largish btrfs fs does make this somewhat of an unusual case.

I guess if I were to debug this my next steps would be:

  - reproduce the problem, and at step 3 above run "rpcdebug -m rpc -s cache", then get the contents of /proc/net/rpc/*/content; they may show that the server is trying to ask mountd about the problem export?

  - reproduce the problem and get a network trace showing all the traffic between the problem client and server.  Look in particular for rpc's that the client is sending to the server without getting any reply.

sounds like you're thinking its a network/rpc issue, no?

I also wonder if btrfs is doing something that keeps the fs from *really* being available. wish there was someway I could put the nfsserver in debug or maybe extra logging mode to see the errors/chatter...but I guess thats what your doing on the rpc, net trace suggestion. thanks much.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.