Bug 439093 - NFSv4: wait for CLOSE to return before trying to remove
NFSv4: wait for CLOSE to return before trying to remove
Status: CLOSED DUPLICATE of bug 565974
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.2
All Linux
low Severity medium
: rc
: ---
Assigned To: Steve Dickson
Red Hat Kernel QE team
http://bugzilla.linux-nfs.org/show_bu...
:
: 456445 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-26 18:26 EDT by chris vogan
Modified: 2010-10-21 09:53 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-10-21 09:53:59 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 chris vogan 2008-03-26 18:26:21 EDT
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 Product and Program Management 2008-07-25 13:05:07 EDT
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 13:13:11 EDT
*** Bug 456445 has been marked as a duplicate of this bug. ***
Comment 4 Ludek Smid 2008-07-25 17:54:04 EDT
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 11:37:20 EDT
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 09:53:59 EDT

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

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