Date: Wed, 29 Feb 2012 20:52:14 -0500 From: Garrett Wollman <wollman@bimajority.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs@freebsd.org Subject: Re: Under what circumstances does the new NFS client return EAGAIN? Message-ID: <20302.54862.344852.13627@hergotha.csail.mit.edu> In-Reply-To: <148631084.149332.1330561285089.JavaMail.root@erie.cs.uoguelph.ca> References: <20302.29963.529821.258448@hergotha.csail.mit.edu> <148631084.149332.1330561285089.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Wed, 29 Feb 2012 19:21:25 -0500 (EST), Rick Macklem <rmacklem@uoguelph.ca> said: > If you are using the "soft" or "intr" mount options, I'd suggest you > get rid of them (technically "intr" should result in EINTR, but I wouldn't > be surprised if an EWOULDBLOCK could pop out, as well). Also, you > didn't mention whether you were using UDP or TCP mounts, although the > above comments should apply to both. mount -t nfs -o ro,hard,tcp,nointr > You might also want to capture packets and look at them in wireshark, > to make sure the EWOULDBLOCK isn't coming from the proprietary NAS server. Unfortunately, I can't capture packets on this machine fast enough to record a decodeable NFS/TCP stream with the NAS. Another bug I've noticed: when mounting any remote NFS filesystem, all of the local exported NFS filesystems briefly give [EPERM] (or maybe it's [EACCES]) errors to their clients. This tends to break whatever is trying to use them at the time. It doesn't happen when local ZFS datasets are created and mounted. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20302.54862.344852.13627>