NFS and stat() calls

[ Edited ]

I realise that this question might fall into the 'How long is a piece of string' category but...


I have a directory structure on a local HDD that consists of 6533 directories, 33662 files and contains ~2.5GB.

I also have an exact copy of this in a volume on an AFF8040 running CDOT 8.3.1P1 and mounted via NFSv3.

The server is a Dell M620 blade with 128GB and a 300GB SAS HDD connected via a 10Gbe link to a Cisco Nexus 5K switch which is connected to the AFF8040

My question can be summarised by the following:


$ time find /mnt/test/test_hdd/ -ls >/dev/null

real 0m0.277s
user 0m0.124s
sys 0m0.150s

$ time find /mnt/test/test_ssd/ -ls >/dev/null

real 0m8.070s
user 0m0.290s
sys 0m0.898s


A factor of ~30 seems to be rather high to me but I don't have any other information to compare it against.


Is this the sort of time difference I should expect to see in these circumstances or is there something I can do to improve the response time?

Re: NFS and stat() calls

Local access will always be faster than network access.


I can't comment on the latency time you are seeing, but I know that NFS used in the manner you are using tends to be a serialized process. For this specific test, you can certainly see some delays.


Also, network can factor in.


I'd recommend having a look at XCP for this sort of test. That allows things to be be done more in parallel.


We've seen some pretty impressive numbers for operations high in metadata access, such as ls or find. Give it a shot.

Re: NFS and stat() calls

Maybe filesystem cache is coming into play here?  Your NFS mount is shared storage that could be changing and thus must be queried each time vs a disk/LUN where the filesystem is owned by the client and the state can be cached.  Maybe you could unmount both, or better yet, reboot, and mount, and then prior to doing anything run the commands again?  And then now without rebooting another time?  Just curious to see if there are differences on fresh boot without caches, and then on a repeat where caches could influence.


Chris Madden



If this post resolved your issue, please help others by selecting ACCEPT AS SOLUTION or adding a KUDO