Re: nfs kernel booting is slow

[scole_mail <scole_mail%gmx.com@localhost>]

christos%astron.com@localhost (Christos Zoulas) writes:

> In article <1A9C6071-D675-4340-AC01-8D3D01F2E547%must-have-coffee.gen.nz@localhost>,
> Lloyd Parkes  <lloyd%must-have-coffee.gen.nz@localhost> wrote:
>>
>>
>>> On 20/11/2017, at 1:58 PM, Michael van Elst <mlelstv%serpens.de@localhost> wrote:
>>> 
>>> scole_mail%gmx.com@localhost (scole_mail) writes:
>>> 
>>> Both seem to be slow, look at the time stamps and repeated requests
>>(same xid).
>>> Sure that one is a dump from a 'working' setup?
>>
>>
>>I agree with Michael that the dump from the “working” setup
>>doesn’t look healthy at all.
>>
>>I have seen similar problems relating to NFS and a lack of flow control
>>before (as paul mentioned), but these read requests all fit inside a
>>single ethernet frame, so you shouldn’t need any flow control. You are
>>only ever waiting for one packet and you really shouldn’t need flow
>>control. 
>>
>>One thing I have seen is horrifyingly slow network interfaces speaking
>>10base-T. I had to rate limit traffic to a SAN switch’s 10base-T
>>management port because it simply couldn’t handle traffic coming in at
>>10Mb/s and firmware updates via FTP were timing out. Maybe the powermac
>>is half-duplex (which is reasonable for 10base-T) and it can’t switch
>>from transmit to receive fast enough to read the reply properly (which
>>is me being super speculative). Try setting your NFS server’s network
>>link to a slower speed, such as 10base-T just to see if that helps. 
>
> Try mounting with rsize=1024,wsize=1024?
>
> christos

I reposted a corrected "working" set.  Unfortunately, these are all
unmanaged switches.

The rsize/wsize options didn't seem to make a difference either way.

Thanks for the suggestions so far.