HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
cancel
Showing results for 
Search instead for 
Did you mean: 

RE: NFS issue

 
SOLVED
Go to solution
Adam Noble
Super Advisor

RE: NFS issue

Hi all,

I think this is a complex issue and not sure if anybody is going to have the answer. I am trying a simple test to try and understand a larger issue. I have two server A and B which have an NFS share mounted from server C. They are all running 11.31. I have a 1GB compressed files which grows to 3GB uncompressed. It resides within the nfs share.

Ok so if I carry out an uncompress on server A and then do a listing from another window of the same share on the same server it hangs. If I do the listing on Server B it instantly returns the directory listing. It works exactly the same the other way round. So I tried to assess is this the pipe from server to switch or the OS.

So what I did was mounted the NFS locally if that makes sense. I simply mounted /var/adm/crash to the same server as /crash. So surely there is no network involved. Sure enough however I get exactly the same behaviour the listing hangs when an uncompress takes place. So this to me has to relate to the way NFS is handling the request. Is this what I should expect?

3 REPLIES
Shibin_2
Honored Contributor

Re: RE: NFS issue

How about the patch level of NFS components in those servers ?
Regards
Shibin
Steven Schweda
Honored Contributor

Re: RE: NFS issue

> I think this is a complex issue [...]

I sure seems that way. Especially when you
try to describe everything, and show nothing.
Is there any chance of seeing the actual
commands you're running, and their actual
output?

> [...] mounted the NFS locally if that makes
> sense. [...]

It makes no sense to me.
Dave Olker
HPE Pro
Solution

Re: RE: NFS issue

Sounds like the uncompress is using lots of file cache and when you issue the "ll" command it wants the updated attributes of the files in the directory so it is waiting for the pages in file cache to flush to disk so it can get the accurate attributes, like file size.

What happens if you do an "ls" instead of "ll"? You can also try mounting the filesystem with direct I/O as a test, as that will bypass the cache. If you mount the filesystem with "-o forcedirectio" and try the uncompress/ll combination see if you get different results.

Dave