Re: NFS client hangs after server reboot

[Rick Macklem <rmacklem@uoguelph.ca>]

Bram Vandoren wrote:
> > It's not typical for a client with an active workload to wait 4400
> > seconds to send a fresh SYN. Bram, can you shed any light on this?
> 
> The server was down for ~4400 seconds (I started the capture before
> the maintanance period). I captured the packets using a switch mirror
> port (it's possible some packets are lost during capture). After a
> while an arp timeout occurs and we don't capture the SYNs from the
> client any more (I doubt the client sends the SYN because it doesn't
> know where to send it).
> 
> If it helps, I can filter extra information from the big pcap file
> (~20G) (eg capture from other clients or from the same client just
> before the server reboot).
> 
> Thanks,
> Bram.
Did both the client and server have the same IP addresses before the
reboot?

If not, the Linux client's nfs_client_id4.id SetClientID argument
will be different (it has the client/side IP# in it). nfs_client_id4.id
isn't supposed to change for a given client when it is rebooted.
That will make the FreeBSD NFSv4 server see "new client" (which is not in the
stablerestart file used to avoid certain reboot edge conditions) and
will not give it a grace period. 
This is the only explanation I can think of for the NFS4ERR_NO_GRACE
reply shortly after the reboot.

I'd guess the RSTs are because the nfsd has terminated (nothing on
port# 2049) just before the system was shut down, so I suspect the
RSTs are not an issue? (I have assumed the packet trace started after
the server rebooted.)

rick