Weird NFSvs rdirplus issues

[Mike Andrews]

On Thu, 18 Mar 2004, Mike Andrews wrote:

> The motivating factor in using readdirplus at all is that it drastically
> reduces CPU load, ethernet load, and NFS ops/sec on the Netapps, which are
> not exactly cheap to upgrade CPU in.  When I turned readdirplus off to
> stop the file corruption, the Netapp's CPU load pegged at 100% around the
> clock. But interestingly, it doesn't seem to raise the actual disk spindle
> ops/sec; probably the extra stat() calls are being handled from its disk
> cache.  Still, the overhead of quadruping the number of NFS calls is too
> much for it...

Actually, it turns out the load was caused by a client process that got
stuck right about the same time I was experimenting with different mount
options.  Oops.  I'm running without rdirplus with normal performance now.
Still wish I understood the ac options a bit better though.

There's still the issue of mount_nfs dumping core in 4.9 though, if
it wasn't already backported from -current to -stable for 4.10...

> Bizarre situation #1 is the easy one: when you try to put the acdirmin/max
> and acregmin/max options on an NFS filesystem in /etc/fstab, mount
> (actually mount_nfs) will dump core on 4.9-RELEASE-p4 but not on
> 5.2.1-RELEASE-p3:
>
> # grep acreg /etc/fstab
> server:/fs /mnt nfs,ro,-lis,acdirmin=0,acdirmax=1,acregmin=0,acregmax=1 0 0
> # mount /mnt
> mount: server:/fs: Segmentation fault
>
> (the core file left behind is for mount_nfs, not mount, though)
> However running mount_nfs at the command line will work, even on 4.9:
>
> # mount_nfs -lis -o acdirmin=0,acdirmax=1,acregmin=0,acregmax=1 server:/fs /mnt
>
> Looks like some kind of parsing error that the fix hasn't been MFC'ed for?
> (I haven't been able to check 4.9-STABLE yet to see if the fix made it there.)


Mike Andrews  *  mandrews at bit0.com  *  http://www.bit0.com
"The truth is, you never find the truth."     Carpe cavy!
It's not news, it's Fark.com.