[00:17] <sarnold> well that's interesting, I wonder what the heck *that* means
[00:31] <rfm> it must mean fns can't decode int incoming rpc calls.  hard to see that being anything other than network troubles. maybe the local mounts are slow too because the server's being beat to  death with retries from the net? 
[00:33] <sarnold> hmmm try ip -h -iec -s l
[00:33] <sarnold> holy cow i've got a crap network
[00:44] <dak_> sarnold, Nothing standing out at me when running that command. No errors, 3 dropped packets (TX) for the interface that the datasets are shared through. 
=== keithzg_ is now known as keithzg
[00:45] <sarnold> dak_: well, that's good news anyway :)
[00:46] <dak_> sarnold, indeed :)
[00:47] <JanC> somethig with a broken NFS implementation trying to use the server?
[00:50] <dak_> JanC, hard to say. I was surprised that mounting a NFS share locally (localhost) on the NFS server itself still had horrible performance. As I expected it to be a network issue upstream of the server. Maybe I should try shutting down all interfaces so nothing is coming into the NFS server and trying a local mount again through the drac. Its very strange.
[01:20] <patdk-lap> are you using sync nfs mount?
=== holmanb is now known as holman
[03:21] <dak_> patdk-lap, we dont pass sync or async as an option. So whatever the default is (async?). However, keep in mind that this NFS server's performance was fine until it suddenly wasn't, and its been seemingly getting worse. This has been in production since May, only started having problems about a week ago. I have my doubts that async vs sync would make a difference.
=== esembee_ is now known as esembee
=== trekkie1701c_ is now known as trekkie1701c