[Bugs] [Bug 1465075] New: Fd based fops fail with EBADF on file migration

bugzilla at redhat.com bugzilla at redhat.com
Mon Jun 26 15:09:04 UTC 2017


https://bugzilla.redhat.com/show_bug.cgi?id=1465075

            Bug ID: 1465075
           Summary: Fd based fops fail with EBADF on file migration
           Product: GlusterFS
           Version: mainline
         Component: distribute
          Assignee: bugs at gluster.org
          Reporter: nbalacha at redhat.com
                CC: bugs at gluster.org



Description of problem:

In DHT, there exists a scenario where fd based fops may be sent on the dst
subvolume after the file has been migrated but before the fd has been opened on
it. This is because certain operations update the cached subvol in the dht
inode ctx without checking to see if an fd has been opened on it on the
original subvol. Dht fd based fops currently rely on a phase1/phase2 migration
checks to open fds on the dst subvol. However, no such check is made causing
the fop to fail with EBADF.

This is seen with dist-rep volumes.



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


How reproducible:


Steps to Reproduce:

1. Create a 2x2 volume
2. Create a file FILE1. Assume it is created on subvol1. Rename it to NFILE1 so
it hashes to subvol2.
3. Open an fd on NFILE1 (on subvol1).
2. Perform a rebalance so the file is migrated to subvol2.                      
3. On the same mount point, perform a lookup/readdirp so the cached subvol in
the inode_ctx of NFILE1 is updated to subvol2.          
4. Perform a write on the fd.

The write is sent to subvol2 on an fd which has been opened only on subvol1.   
     Since the migration phase checks don't kick in, the fd is not opened on
subvol2 and the fop fails with EBADF.

Actual results:


Expected results:


Additional info:

This is being fixed by having every fd based fop check if the fd has been
opened on the cached subvol before winding the fop down.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the Bugs mailing list