Bug 990089 - do not unlink the gfid handle upon last unlink without checking for open fds
do not unlink the gfid handle upon last unlink without checking for open fds
Status: CLOSED EOL
Product: GlusterFS
Classification: Community
Component: fuse (Show other bugs)
mainline
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Raghavendra Bhat
:
: 1259995 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-30 07:16 EDT by Raghavendra Bhat
Modified: 2015-10-22 11:46 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-22 11:46:38 EDT
Type: Bug
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 Raghavendra Bhat 2013-07-30 07:16:06 EDT
Description of problem:

As of now, any fd based operations fail with EBADFD, if after the last unlink of the file a graph change is done.

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


How reproducible:
Always


Steps to Reproduce:
1. create a volume, start it and mount it.
2. Create a file
3. Open the file
4. Unlink the file
5. do a graph change (some performance xlators on/off)
6. Try to write to the fd opened

Actual results:
The write operations fail with EBADFD

Expected results:
Write operations should succeed

Additional info:

Reason:
Upon the unlink of the file (in fact upon the removal of the last hard link for the file) the gfid handle from the .glusterfs directory in the brick is removed. Now,upon the graph change, the client process cannot find the inode for the fd in the new graph. So to get the inode, it does a nameless lookup using the gfid (which gets the inode by getting the information from the gfid handle present in the .glusterfs directory). But since the gfid handle has been removed, the new inode cannot be obtained, and the fd is marker as bad.

To handle it, the gfid handle should be removed upon the removal of the last reference to the file (i.e there should not be any open fds and should not be any entries in the filesystem).
Comment 1 Anand Avati 2013-07-30 07:19:46 EDT
REVIEW: http://review.gluster.org/5428 (storage/posix: remove the gfid handle only when the last reference in removed) posted (#1) for review on master by Raghavendra Bhat (raghavendra@redhat.com)
Comment 2 Anand Avati 2013-07-30 14:53:49 EDT
REVIEW: http://review.gluster.org/5428 (storage/posix: remove the gfid handle only when the last reference in removed) posted (#2) for review on master by Raghavendra Bhat (raghavendra@redhat.com)
Comment 3 Anand Avati 2013-08-22 08:47:15 EDT
REVIEW: http://review.gluster.org/5428 (storage/posix: remove the gfid handle only when the last reference in removed) posted (#3) for review on master by Raghavendra Bhat (raghavendra@redhat.com)
Comment 4 Anand Avati 2013-08-26 08:13:25 EDT
REVIEW: http://review.gluster.org/5428 (storage/posix: remove the gfid handle only when the last reference in removed) posted (#4) for review on master by Raghavendra Bhat (raghavendra@redhat.com)
Comment 5 Anand Avati 2013-12-12 06:44:24 EST
REVIEW: http://review.gluster.org/5428 (storage/posix: remove the gfid handle only when the last reference in removed) posted (#5) for review on master by Raghavendra Bhat (raghavendra@redhat.com)
Comment 6 Raghavendra G 2015-09-04 04:51:40 EDT
*** Bug 1259995 has been marked as a duplicate of this bug. ***
Comment 7 Kaleb KEITHLEY 2015-10-22 11:46:38 EDT
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.

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