NFSD_CGI is the web-interface for the NFSD (Server) on Freetz.
Some observations: Currently using NFS with a 7390 using Freetz-trunk revision 11466. Using this revision I didn’t observe permission issues like with Freetz-1.2 for my 7270v3. As mount I’m using a NDAS-NetDisk which is Ext3 formatted.
My currect config allows 192.168.178.0/24 and localhost (for the local NFS Client).
/var/media/ndas/ext3 192.168.178.0/255.255.250.0(rw,no_subtree_check) localhost(rw)
Looks only the first two lines are needed, but the others should not harm.
mountd,nfsd,portmap: 192.168.178.0/255.255.255.0 , localhost lockd: 192.168.178.0/255.255.255.0 , localhost rquotad: 192.168.178.0/255.255.255.0 , localhost statd: 192.168.178.0/255.255.255.0 , localhost
Only deny the NFS related services
mountd,nfsd,portmap:ALL lockd:ALL rquotad:ALL statd:ALL
Below some helpfull commands for trouble-shooting on the server.
nfsstat where not available on my FB.
rpcinfo is available if ‘replace kernel’ is used.
List of kernel supported filesystems by the FB:
Just look if the filesystems you are planning to use are listed.
Status should be
running. Use the following
ps command first to see
which processes are actually running before restarting the nfs server.
ps -wl | grep 'nfs|portmap|lockd|statd|mountd|quota'
portmap, lockd, mountd, and nfsd should be all listed as a process.
You can use
/etc/init.d/rc.nfsd stop and
to stop and start the nfs server.
Should show the hosts or subnets (incl. localhost if configured) configured in /etc/exports
Look that the mounted disk allows rw (if intended)
If you also have the NFS Client installed on the FB, the following verification is available:
mount -t nfs localhost:/<share-path> /<mount-point>
To show from the server which nfs exports are in use:
showmount --all showmount --exports
To verify layer-4 network information (e.g. used ports):
The read and write buffers are assigned during the
mount on the
The server supports a buffer size that range from 4kbytes to 1024kbytes
(RPCSVC_MAXPAYLOAD (110241024u)) in steps of 1kbyte.
Finding the optimal buffer size is normally the best option to get a
I only have a ndas Net-Disk mounted, and found that all rsize values had
a similar variation in the results.
The FB CPU is the bottleneck.
It might be interesting to retest this with a USB-stick to see if than
varying the buffersizes would show a difference.
For this I used two scripts to: run the test, unmount/mount both client and server mounts, restart nfsd, and mounted the client with a different rsize parameter. During the tests I only varied the rsize parameter, because I’m only interested in the read optimalisation now, but changing both wsize and rsize is also possible. Each test takes about 35 minutes (with 1gigbyte transfers), so you can do about 16 overnight. Here the scripts I used:
#!/bin/sh # the initial test with a rsize of 32768 (=32k) and increased with steps of 32k to 1024k # rsize=32768 # for the second test again 32 test using 1gigabyte using the best result -16*1k to +16*1k # rsize to test is rsize=294912. Start rsize is rsize=(294912-16384) i=1 date > results.txt date +%s >> results.txt while [ $i -le 32 ]; do echo ======================================================= >> results.txt echo ======================================================= echo setup bonny++ test with rsize of $(($rsize+1024*$i)) echo setup bonny++ test with rsize of $(($rsize+1024*$i)) >> results.txt mount -o hard,intr,rsize=$(($rsize+1024*$i)) 192.168.178.1:<full_share_path> <local_mount_point> bonnie++ -d <local_mount_point> -s 1g -n 0 -m nfs_client_$rsize -f -b -u root >> results.txt 2>> results.txt echo ======================================================= >> results.txt umount <local_mount_point> expect autologin.sh i=$(($i + 1)) done date >> results.txt date +%s >> results.txt
#!/usr/bin/expect spawn ssh firstname.lastname@example.org # expect "connecting (yes/no)?" # send "yes" expect "assword:" send "<your_passwd>" expect "#" send "/etc/init.d/rc.nfsd stop" expect "done." send "umount /dev/nda2" expect "#" send "mount /dev/nda2 <mount-point>" expect "#" send "/etc/init.d/rc.nfsd start" expect "done."
You can obtain a nice html page of your results with:
cat results.txt | grep ,,, | bon_csv2html > /tmp/nfs_client_test.html
But you can also use the csv format output in an Excel sheet. I attached 3 html files showing my results.
In the MRTG graph of the CPU Utilization you can clearly see that the CPU Utilization is the bottleneck in my setup using a NDAS NetDisk. The picture shows I started the test at about 7:20am which took until 1:10am the next day. Than I did two manual bonny++ tests at 1:15am and 2am. Than started a new batch test using the scripts at about 2:45am.