(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.)

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.

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!

(edit by TomTalpey? to strike through the client sync option. This option single-threads all NFS writes and completely kills write performance. See shettj's result in the table below, for example. It is useful only if the server is misbehaving badly.)

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

 || 4231 || 3820 || 3764 || 3261 || 56 || 5278 || 5224 || 4830 || 4129 || 165 ||

 /share/hdd/data   192.168.0.0/255.255.0.0(rw,sync,all_squash,anonuid=0)

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.

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.

Editing with OpenOffice.org works fine now !

NFS and OpenOffice?

Problem : when using [http://www.openoffice.org/index.html 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 [http://www.openoffice.org/index.html 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,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,all_squash,anonuid=0)
 /share/flash/conf 192.168.0.0/255.255.0.0(ro,sync,no_root_squash)

Editing with [http://www.openoffice.org/index.html 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>

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!

By JamesCC?: If you are a nfs novice, you might want to have a read of unfs3 package (just for setting up exports file and clients). When mounting on the clients, I found using default nfs options seemed to make it take 5+ minutes to mount. I following settings gave practically immediate mounting (I've include 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!

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

Speed measurement

manual

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 - anyway use it at your own risk!

Benchmark results:

 dyoung-HNY: http://de.groups.yahoo.com/group/nslu2-german/message/47

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

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.

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

Please add content here.