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 5 product line. The current stable release is 5.10. 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 439093

Summary:	NFSv4: wait for CLOSE to return before trying to remove
Product:	Red Hat Enterprise Linux 5	Reporter:	chris vogan <chrisvogan>
Component:	kernel	Assignee:	Steve Dickson <steved>
Status:	CLOSED DUPLICATE	QA Contact:	Red Hat Kernel QE team <kernel-qe>
Severity:	medium	Docs Contact:
Priority:	low
Version:	5.2	CC:	jburke, jlayton, steved
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
URL:	http://bugzilla.linux-nfs.org/show_bug.cgi?id=150
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-10-21 13:53:59 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 chris vogan 2008-03-26 22:26:21 UTC

Description of problem:
NFSv4 issue with RHEL5 system. 
Problem also is seen on Fedora 7 and 8 systems.
NFSv4 client does not wait for the Close call to return before issuing a remove
request.  The result is the file is renamed to .nfsxxxxxx before being removed.
In a simple test program the close function was issued before the remove.  In a
network trace you can see the close call, but the nfsv4 client sent a rename
before the close call had a chance to return.  

Version-Release number of selected component (if applicable):
Kernel level: 2.6.18-53.1.14.el5

How reproducible:
Simple C program:
Open fd
Stat fd
Close fd
Remove fd

Steps to Reproduce:
1.Mount NFSv4 share
2.Run test program to open,stat,close,remove file to mount point.
3.Unmount NFSv4 share
  
Actual results:
The file was not removed. It was renamed then removed after the test program
completed. Network trace showed these results.
> CALL CLOSE
> CALL LOOKUP <- rename to replace remove
> REPLY CLOSE
> REPLY LOOKUP

Expected results:
> CALL CLOSE
> REPLY CLOSE
> CALL REMOVE
> REPLY REMOVE

Additional info:

There is a fix for this problem by University of Michigan CITI NFSv4 team.
See Bugzilla: http://bugzilla.linux-nfs.org/show_bug.cgi?id=150
and/OR
http://git.linux-nfs.org/?p=trondmy/nfs-2.6.git&a=commitdiff&h=a49c3c7736a2e77931dabc5bc4a83fb4b2da013e

Comment 2 RHEL Program Management 2008-07-25 17:05:07 UTC

This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 3 Peter Staubach 2008-07-25 17:13:11 UTC

*** Bug 456445 has been marked as a duplicate of this bug. ***

Comment 4 Ludek Smid 2008-07-25 21:54:04 UTC

Unfortunately the previous automated notification about the
non-inclusion of this request in Red Hat Enterprise Linux 5.3 used
the wrong text template. It should have read: this request has been
reviewed by Product Management and is not planned for inclusion
in the current minor release of Red Hat Enterprise Linux.

If you would like this request to be reviewed for the next minor
release, ask your support representative to set the next rhel-x.y
flag to "?" or raise an exception.

Comment 5 chris vogan 2009-03-27 15:37:20 UTC

Fedora has resolved this issue with Patchs from git in Fedroa 8.
Can this same patch be used to address the close remove issue reported in this BUG? We are gated from using Redhat kernels because of this issue.

Patches below:
http://git.linux-nfs.org/?p=trondmy/nfs-2.6.git&a=commitdiff&h=a49c3c7736a2e77931dabc5bc4a83fb4b2da013e

Comment 7 Steve Dickson 2010-10-21 13:53:59 UTC


*** This bug has been marked as a duplicate of bug 565974 ***