This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 461056 - Large number of LOOKUP operations by an NFS client suggests caching isn't working
Large number of LOOKUP operations by an NFS client suggests caching isn't wor...
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Don Howard
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-03 16:37 EDT by Tom Georgoulias
Modified: 2009-05-29 18:44 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-05-29 18:44:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom Georgoulias 2008-09-03 16:37:04 EDT
Description of problem:

I am seeing an excessive number of LOOKUP operations by an NFS client, suggesting that it isn't properly caching file handles.  Clients that were suffering from this were fixed by unmounting, then remounting the NFS export, or rebooting.  The large number of LOOKUP operations on the client side were also showing up as increased NFS operations on the Netapp filer.

Version-Release number of selected component (if applicable):

2.4.21-47.0.1.ELhugemem i686

How reproducible:

Every time, although I am unsure what caused this behavior to start.  Server has been online for 64 days, problem really flared up 17 days ago.

Steps to Reproduce:
Unsure how to reproduce this.
  
Actual results:

Data from nfsstat -c on a client with the problem:

Client nfs v3:
null       getattr    setattr    lookup     access     readlink   
0       0% 1048958609 19% 0       0% -1651855508 49% 1349795992 25% 1627002  0% 
read       write      create     mkdir      symlink    mknod      
301676403  5% 0       0% 0       0% 0       0% 0       0% 0       0% 
remove     rmdir      rename     link       readdir    readdirplus
0       0% 0       0% 0       0% 0       0% 43      0% 6976    0% 
fsstat     fsinfo     pathconf   commit     
20      0% 9       0% 0       0% 0       0% 

Expected results:

nfsstat -c data from a client where the export was remounted:

Client rpc stats:
calls      retrans    authrefrsh
795066531   397        0       
Client nfs v3:
null       getattr    setattr    lookup     access     readlink   
0       0% 1066345453 20% 1       0% -1919703917 46% 1345397300 26% 1629669  0% 
read       write      create     mkdir      symlink    mknod      
301387612  5% 8       0% 1       0% 0       0% 0       0% 0       0% 
remove     rmdir      rename     link       readdir    readdirplus
0       0% 0       0% 0       0% 0       0% 155     0% 10104   0% 
fsstat     fsinfo     pathconf   commit     
132     0% 13      0% 0       0% 0       0% 

Additional info:
Comment 1 Don Howard 2008-11-20 12:37:37 EST
Hi Tom -

There's not enough info here to make any suggestions as to what might be causing the increase nfs transactions you are seeing.  There have been several nfs bugs fixed since 2.4.21-47.0.1.  Can you reproduce this issue with the latest rhel3 kernel (2.4.21-57.EL)? 

Have you had a chance to open a ticket with Red Hat support at support.redhat.com?  If not, please do.  

Note: Bugzilla is used to track bugs once they have been triaged.  There are no service guarantees associated with a bugzilla ticket.

Note You need to log in before you can comment on or make changes to this bug.