Shehjar Tikoo wrote:
Gordan Bobic wrote:
I can't figure out why this might be the case, but it would appear
that when unfsd is bound to a custom port and not registered with
portmap, the performance is massively improved.
I changed my init.d/unfsd script as follows, in the start option:
- /usr/sbin/unfsd -i ${pidfile} + /usr/sbin/unfsd -e /etc/uexports
-i ${pidfile} -m 12049 -n 12049 -p
How was your experience with LD_PRELOADed booster instead of going
through a FUSE mountpoint?
I never tried it. I was informed by one of the developers that booster
is not particularly helpful, can cause stability problems and is soon to
be deprecated in the 3.0.x branch.
cat /etc/uexports /home 10.2.0.0/16(rw,insecure)
On the client side I am mounting with:
server:/home /home nfs
defaults,nolock,hard,noatime,proto=udp,rsize=32768,wsize=32768,port=12049,mountport=12049
0 0
You're using UDP. Are you sure NFS client did not default to TCP
earlier when you were not specifying non-default ports?
Considering this is on a LAN, I would expect the difference in
performance between TCP and UDP to be approximately the difference
implied by the header sizes: 8 bytes for UDP vs. 20 bytes for TCP. I
wouldn't imagine that to make that much difference on the payload of 32KB.
I can try TCP vs. UDP but I'm reasonably sure I've always mounted NFS
volumes via UDP. In fact, unfsd shares refuse to mount TCP at the moment.
All of the horrible latency and laggyness is completely gone! Could
it be that it is unfsd's interraction with rpc/portmap/mountd that
is the cause of a lot of the performance issues?
unfsd only needs to register with portmap once when it starts so I
dont think that is the reason.
I didn't think it would be, either, but something is quite clearly
different and is making a massive difference.
Gordan
