topic NAS 1000s NFS problem in StoreEasy Storage

NAS 1000s NFS problem

Terry Hudson — Tue, 22 Jun 2004 10:23:09 GMT

I have managed to set up an NFS share but when I attempt to copy anything into this share the NAS hangs up completely. I have switch off the server to recover from this.
The client side hangs and I have to do a forced unmount for it to recover.

Re: NAS 1000s NFS problem

CA1083075 — Tue, 06 Jul 2004 15:07:58 GMT

Terry,

I have some questions and a few suggestions:

1) Does the hang occur immediately when you start the copy, or does it hang sometime during the copy?

2) What client OS are you running (i.e. Redhat x.x, HP-UX, et)?

3) Did you map the users and groups? If so, can you run: mapadmin list -all and post the output to the forum?

4) If you are using the user root, make sure you have set it to allow root access.

5) Make sure you install the latest patches as listed at: http://h18023.www1.hp.com/support/files/server/us/locate/73_5622.html especially SAK 2.01 Service Pack 1a

-Monty

Re: NAS 1000s NFS problem

Terry Hudson — Wed, 07 Jul 2004 03:43:25 GMT

The hang occurs after 3-4 files have been copied.
The client OS is RedHat 7.3
The users and groups are mapped using the advanced user mapping and show up if you do a mapadmin -list all
I do use a root access and root acess is allowed
It was after I installed patch Q330032 that this problem occured.

I have just applied Microsoft Windows 2000 service pack 4 and this seems to have cured the problem!!

Having said this the speed of transfer when copying to the NFS share seems very slow.

Is this a further problem?

Re: NAS 1000s NFS problem

CA1083075 — Wed, 07 Jul 2004 10:24:56 GMT

Hi Terry,

Glad to hear SP4 resolved the hang issue.

I have seen slow performance issues with RedHat 7.3 systems and have been able to greatly increase performance by using the mount options: mount -t nfs -o tcp,rsize=32768,wsize=32768 host:/share /mount-point

For example, some of my test results:

Test #1 -- default mount options (i.e. mount :/hp /hp
=========
-- cp /data/testnfs.tar /hp/testnfs.tar
-- time it took for 2GB file copy: 82m13.626s

Test #2 -- mount with 32K block size
=======
-- cp /data/testnfs.tar /hp/testnfs.tar
-- umounted nfs share and mounted with the following options:
mount -t nfs -o tcp,rsize=32768,wsize=32768 15.27.101.64:/maxtor /maxtor
-- time it took for 2GB file copy: 4m7.663s <------ Huge Difference

Usually, this behavoir is seen in the /var/log/messages with the errors:

kernel: nfs: server server.domain.name not responding, still trying
kernel: nfs: task 10754 can't get a request slot
kernel: nfs: server server.domain.name OK

Later versions of Redhat do not seem to have this issue.

Let me know how it goes.

- Monty

Re: NAS 1000s NFS problem

Terry Hudson — Thu, 08 Jul 2004 08:38:29 GMT

Hi Monty

I have tried the rsize and wsize values you suggested.

This has increased the performance a great deal. Thanks!!

I am now managing to transfer 290Mbytes in 10 minuites. This still seems slower than your quoted figures but I guess it depends upon the types of files you are transferring.

I am considering using the nfsonly.exe option on the nfs share to try and speed it up a little more.

Do you think think this is a good idea?

Re: NAS 1000s NFS problem

CA1083075 — Thu, 08 Jul 2004 15:11:02 GMT

Hi Terry,

I'm glad to hear those mount options helped. If this share will only be used for NFS, then I would recommend using the NFS Only option. Also, you are correct about the type (especially the size of the files) can make a difference in performance.

The NFS Only option provides faster NFS performance and is intended for NFS clients only. The executable file, nfsonly.exe, allows a share to be modified to do more aggressive caching to improve NFS performance. This option can be set on a share-by-share basis. Do not use this function on any file share that can be accessed by any means other than by NFS clients, as data corruption can occur.

Also note that the NFS service must be restarted after setting up an NFS Only share.