Bug 990089

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).