Hi all,
I have a 520 filer running 5.3.7R2 (firmware 2.1_a) with what I perceive to be a problem - I need someone to tell me if this is normal or not.
Essentially, when I transfer a single big file (100 MB is my test file) to it over NFS, the CPU pegs at between 98% and 100% for the duration of the transfer (about 24 seconds).
This causes some wierd things to happen... I've discovered that if I use NFS version 3 (either TCP or UDP), doing a transfer as above AND trying anything else on the filer (as simple as an 'ls -l') will cause the data transfer to break, i.e. the 'cp' will exit with an error "write: Resource temporarily unavailable". In actual fact, the transfer does not STOP, it continues in the background, however the copy returns an error code and the above message.
Using NFS version 2, either TCP or UDP, the cp completes properly.
Because the CPU is pegged, the aforementioned 'ls' can take 10 or more seconds in a directory with perhaps 10 files in it... not too good.
I find this to be bizarre behaviour... both the CPU getting pegged while transferring a single file, and the copy breaking... has anyone else seen this?
Cheers,
Ross
What sort of client are you using (ie linux, solaris, sco, hp-ux)?
Mike Smith Escalations Jerk.
Hi all,
I have a 520 filer running 5.3.7R2 (firmware 2.1_a) with what I perceive to be a problem - I need someone to tell me if this is normal or not.
Essentially, when I transfer a single big file (100 MB is my test file) to it over NFS, the CPU pegs at between 98% and 100% for the duration of the transfer (about 24 seconds).
This causes some wierd things to happen... I've discovered that if I use NFS version 3 (either TCP or UDP), doing a transfer as above AND trying anything else on the filer (as simple as an 'ls -l') will cause the data transfer to break, i.e. the 'cp' will exit with an error "write: Resource temporarily unavailable". In actual fact, the transfer does not STOP, it continues in the background, however the copy returns an error code and the above message.
Using NFS version 2, either TCP or UDP, the cp completes properly.
Because the CPU is pegged, the aforementioned 'ls' can take 10 or more seconds in a directory with perhaps 10 files in it... not too good.
I find this to be bizarre behaviour... both the CPU getting pegged while transferring a single file, and the copy breaking... has anyone else seen this?
Cheers,
Ross
Ross Parker | | "Lisp has all the visual appeal of Diagnostic Engineer | oatmeal with fingernail clippings Redback Networks Inc. | mixed in" - Larry Wall parker@redback.com |
On 3 May, Mike Smith wrote:
What sort of client are you using (ie linux, solaris, sco, hp-ux)?
This was a Sun Ultra 5... Solaris 8
Cheers,
Ross
-
Mike Smith -
parker＠redback.com