This provided a performance boost from 1.5Mbyte/sec write speeds to around 8-9.5+ MByte/sec (on 100Meg ENet), and it will preserve the lifetime of my hard disk! ;)

+

+

+

==NFS Write Performance - System Usage ==

+

+

You may find writnig large files over a time will put a load past 5.00 on your NAS, slowing most other services down. I altered the init script of any service which can be a pig to prevent it from hogging the system. This change was made on a FreeLink 1.02 system on a LS-Pro.

+

+

Open /etc/init.d/nfs-kernel-start

+

+

Several bodies would tell you to simply change RPCNFSDPRIORITY=0 to RPCNFSDPRIORITY=5, but for some reason it didn't work with my setup.

+

+

Instead I made this change...

+

+

--nicelevel $RPCNFSDPRIORITY \

+

+

to...

+

--nicelevel 5 \

+

+

Must be a bug w/ the script and I'm too tired to fix it. This works....

NFS is a good choice when remotely accessing files with another Linux/Unix system[1]. Also, particular for the LinkStation NFS overcomes some limitations Apple OS X users have with the LinkStation Samba (not surprising, since OS X is a Unix at heart). Further, NFS on LinkStations is very popular among the DBox2 users[2] (the DBox2 is a set-top box for pay-TV in Germany which can be hacked to record received media streams to e.g. a LinkStaion via NFS).

Currently Kernel-NFS is possible on the LS1, LS HG with 2.6-kernel and on the LS2 with OpenLink and the kernel-modules of the stock kernel.

(this is a custom startscript...it is not that good developed...it can just start at the moment...but it works)

to check if the server is really running execute:

rpcinfo -p 127.0.0.1

if this is working then try rpcinfo -p from a remote workstation (running linux or windows with the "services for unix" installed....only then rpcinfo will b available). there is an entry in /etc/hosts.deny ( portmap: ALL ) that prevents this....

so as long as you do not delete the portmap: ALL entry in /etc/hosts.deny, you have to explicit allow some hosts.

add to hosts.allow

portmap: <host>

if it also works from a different machine then your NFS-Server is running. the only problem should be configuration now.

NFS Write Performance Tweak

Most Default /etc/exports files will give good read performance, but poor write-performance. You'll know when you hear the heads of your NAS disk thrashing wildly.
Change the write mode from sync to async, here is an example from an exports file...

This provided a performance boost from 1.5Mbyte/sec write speeds to around 8-9.5+ MByte/sec (on 100Meg ENet), and it will preserve the lifetime of my hard disk! ;)

NFS Write Performance - System Usage

You may find writnig large files over a time will put a load past 5.00 on your NAS, slowing most other services down. I altered the init script of any service which can be a pig to prevent it from hogging the system. This change was made on a FreeLink 1.02 system on a LS-Pro.

Open /etc/init.d/nfs-kernel-start

Several bodies would tell you to simply change RPCNFSDPRIORITY=0 to RPCNFSDPRIORITY=5, but for some reason it didn't work with my setup.

Instead I made this change...

--nicelevel $RPCNFSDPRIORITY \

to...

--nicelevel 5 \

Must be a bug w/ the script and I'm too tired to fix it. This works....

Portmapper Access Rights

You may have to configure /etc/hosts.allow to allow your client machines to connect to portmap, to make their NFS connections.
I had to do this with my FreeLink 1.02 install on my LS-Pro with my Mac OS X 10.4 client machine(s).

For instance, in /etc/hosts.allow I added the class C range of my local network to allow any RPC client access Ie..

Read [8] or any other exports(5) man page you can get your hands on. Create an /etc/exports file similar to the following

/mnt/hda/share <client ip>(rw,async,secure,root_squash)

Where <client ip> should be the IP address of the client you want to grant access, e.g.

/mnt/hda/share 192.168.0.2(rw,async,secure,root_squash)

if the host 192.168.0.2 should be granted access. Or, for example:

/mnt/hda/share 192.168.0.0/24(rw,async,secure,root_squash)

if the whole 192.168.0.0/24 private subnet should be granted access to the share.

See the exports(5) man page for details. Make absolutely sure that there is no space between <client ip> and (rw,async,secure,root_squash), because this gives you a different, unsecure behavior (not that nfs is very secure, but ...).

NFS isn't the most secure protocol on the planet. It should better not be exposed on the Internet. And it is good custom to lock the portmapper and other daemons down as far as possible. Therefore, create a file /etc/hosts.deny with the following contents:

portmap:ALL
lockd:ALL
mountd:ALL
rquotad:ALL
statd:ALL

So by default no host has access to these daemons (ALL hosts denied). This of course also means our own clients can no longer access these services, and NFS wont work for them. So we have to grant access for the. This is done with the /etc/hosts.allow file. E.g. if the host 192.168.0.2 should have access, write