Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 461056

Summary:	Large number of LOOKUP operations by an NFS client suggests caching isn't working
Product:	Red Hat Enterprise Linux 3	Reporter:	Tom Georgoulias <tomg>
Component:	kernel	Assignee:	Don Howard <dhoward>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Martin Jenner <mjenner>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.9	CC:	dhoward
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-05-29 22:44:36 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tom Georgoulias 2008-09-03 20:37:04 UTC

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 17:37:37 UTC

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.