The package nfs-utils is the package of utilities and configuration files to enable the kernel-mode NFS that is compiled into Unslung-able v3.16 and later.

Be sure that you have the portmap ipkg installed.

Then to use kernel-mode NFS, you first need to:

 ipkg remove nfs-server

if you have been using NFS previously and it is installed. Then you can:

 ipkg install nfs-utils

That's it.

The example exports file is located in /opt/doc/nfs-utils/exports

Copy this file over to /opt/etc/exports and edit it as you wish.

By JamesCC?: If you are a nfs novice, you might want to have a read of the unfs3 package (just for setting up exports file and clients). When mounting on the client (a Gentoo linux PC), I found when using default nfs options it seemed to take 5+ minutes to mount. I found the following settings gave practically immediate mounting (I've included options on by default for clarity)... mount -o vers=3,tcp,sync,nolock,intr,hard,rw <nslu2_ip>:<dir_in_exports> <client_mount_point> ... Maybe it is the use of tcp? Or is it the use of version 3? Who knows but it works for me!

The 'sync' option

See the Linux NFS FAQ and the "Performance" section of the Linux NFS HOWTO for much detail about synchronous vs. asycnhronous mode the effect on performance. A brief summary is as follows:

• If you give the 'sync' option in the mount command, or in /etc/fstab/, the client will wait for the server to confirm that the data has been written to the disk after every write operation. This is safe against conditions such as the disk becoming full, encountering a bad sector, the power failing, or you rebooting the server, and is ideal for valuable data such as files that you are editing. But it can be slow.
• If you give the 'async' option writes may be delayed, and there is no guarantee that the data is actually on the disk until the application closes the file or terminates. This is fine for low-value data where speed is important, e.g. your MythTV? backend.

If you are tempted to use async mode for valuable data, do investigate the other parameters (and in particular try increasing the write block size, wsize) first.

And, according to dyoung:

 dyoung-HNY: kernel nfs is around twice as fast as unfs3; according to some benchmarks our german friends did.
 dyoung-HNY: http://de.groups.yahoo.com/group/nslu2-german/message/47

NFS and OpenOffice?

Problem : when using OpenOffice.org from a Linux client with a default NFS setup as described above, by default documents will be opened as readonly.

Solution : By editing /opt/etc/exports, documents can be updated with OpenOffice.org.

Default /opt/etc/exports :

 /share/hdd/data   192.168.0.0/255.255.0.0(rw,sync,no_root_squash)
 /share/hdd/conf   192.168.0.0/255.255.0.0(ro,sync,no_root_squash)
 /share/flash/data 192.168.0.0/255.255.0.0(rw,sync,no_root_squash)
 /share/flash/conf 192.168.0.0/255.255.0.0(ro,sync,no_root_squash)

After editing :

 /share/hdd/data   192.168.0.0/255.255.0.0(rw,sync,all_squash,anonuid=0)
 /share/hdd/conf   192.168.0.0/255.255.0.0(ro,sync,no_root_squash)
 /share/flash/data 192.168.0.0/255.255.0.0(rw,sync,all_squash,anonuid=0)
 /share/flash/conf 192.168.0.0/255.255.0.0(ro,sync,no_root_squash)

Editing with OpenOffice.org works fine now !

The NSLU2 is mounted by :

 mount -t nfs -o vers=3,tcp,sync,lock,intr,hard,rw <NSLU2 ip>:/share/flash/data/<share name> <mountpoint>

(What you're doing there, by adding "all_squash,anonuid=0", is making the NFS server treat all accesses as if they were done by root. That is a very major security issue. I imagine that the OpenOffice? read-only problem is caused because of some sort of locking problem; you should find and fix that.)

Speed measurement

manual

After some primitive benchmarking of the kernel-mode NFS using copying of the Unslung-able v3.17 build sub-directories residing on a Western Digital 160GB USB 2.0 hard drive over to a local hard drive on a Linux 2.4.24 Debian machine. Transfers are made over a 100MB ethernet full-duplex network through a D-LINK DI-614+ gateway switch and timed using the bash 'time' command.

(I have /home/slug nfs mounted to /share/hdd/data/slug)

Results:

 /home/slug/build/tmp/deploy  -- 110972kB,   890 files ==> (110972 kB / 26.5 sec) = 4187 kB/s read
 /home/slug/build/tmp/staging -- 130896kB, 10515 files ==> (130986 kB / 73.8 sec) = 1773 kB/s read 
 /home/slug/build/tmp/cross   -- 109992kB,  2879 files ==> (109992 kB / 36.2 sec) = 3038 kB/s read

 single 51MB mpg file  -- write to NSLU via nfs:  ==> (52600kB / 25.4 sec)   = 2070kB/s write




 single 255MB mpg file -- read from NSLU via nfs: ==> (261508 kB / 49.1 sec) = 5326 kB/s read

Automatic benchmark:

In the yahoo group's file section you will find a NFS benchmark script (files->other files->nfs_benchmark.tar.bz). The script creates several portfolios on your local harddisk and transfers from your maschine to the slug and back. The throughput is measured and a line for the following table is generated. The script needs about 2.2 GB free space on your local harddisk and on your slug. It only takes about 20 minutes.

So please download the script, customize it and post your results here!

Portfolio overview:

Warning: the script will not delete any files it created - use it at your own risk!

Benchmark results: