NFS flakiness since @ last Friday

[Mohan Srinivasan]

Error 32 is an EPIPE, which NFS will get if the TCP connection 
has been torn down and it tries to send any new data on the 
socket.

The checkin on Thursday was to change the format of the NFS 
sillyrename. It would be surprising if that could cause these
errors. The checkin on Wednesday was to add a new feature -
NFS DirectIO. Which should not be used unless the application
is opening files O_DIRECT. This can be completely disabled
by sysctl'ing nfs_directio_enable to 0.

Since you're seeing EPIPE errors, just to isolate the issue to 
NFS/TCP or NFS/UDP, can you force all mounts to NFS/UDP and see
if the lockups persist ? Also, disable nfs directio completely.

mohan

--- "Conrad J. Sabatier" <conrads at cox.net> wrote:

> I'm seeing some real instability in NFS since approximately last Friday.
> Intermittently, I'm seeing messages such as the following:
> 
> On the client machine:
> 
> Dec 20 23:18:22 dolphin kernel: impossible packet length (1820291) from
> nfs server gateway:/mm
> Dec 21 00:51:47 dolphin kernel: impossible packet length (1746474142)
> from nfs server gateway:/mm
> 
> and
> 
> Dec 21 01:14:41 dolphin kernel: nfs send error 35 for server gateway:/mm
> Dec 21 01:16:33 dolphin kernel: nfs send error 35 for server gateway:/mm
> Dec 21 01:16:38 dolphin kernel: nfs send error 35 for server gateway:/mm
> Dec 21 01:16:40 dolphin kernel: nfs server gateway:/mm: not responding
> Dec 21 01:16:43 dolphin kernel: nfs server gateway:/mm: is alive again
> 
> On the server machine:
> 
> Dec 20 21:52:48 gateway kernel: nfsd send error 32
> Dec 20 21:57:50 gateway kernel: nfsd send error 32
> Dec 20 22:00:45 gateway kernel: nfsd send error 32
> Dec 20 22:23:29 gateway kernel: nfsd send error 32
> Dec 20 23:18:23 gateway kernel: nfsd send error 32
> 
> Then, ultimately, all NFS communication just breaks down
> altogether until a reboot.
> 
> I'm also seeing "sillyrenames" left behind occasionally in nfs-mounted
> directories.
> 
> There were a couple of nfs-related commits last Thursday, which I
> believe are most likely the culprit, although I don't know which ones
> exactly.
> 
> -- 
> Conrad J. Sabatier <conrads at cox.net> -- "In Unix veritas"
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>