Description of problem: Glusterfs client problem "are the same file" Version-Release number of selected component (if applicable):3.4.0.59rhs How reproducible: always Steps to Reproduce: 1. on client1: mkdir test 2. on client1: touch test/foo 3. on client1: ln test/foo test/foo.1 4. on client2: rm test/foo 5. on client1: mv test/foo.1 test/foo Actual results: mv: `test/foo.1' and `test/foo' are the same file Expected results: mv should succeed as test/foo was deleted Additional info:
Verified on: glusterfs 3.4.0.69rhs Fixed. On: 3.4.0.68rhs [root@bob-the-minion gluster]# mv test/foo.1 test/foo mv: `test/foo.1' and `test/foo' are the same file [root@bob-the-minion gluster]# glusterfs --version glusterfs 3.4.0.68rhs built on Sep 10 2014 10:32:45 On: 3.4.0.69rhs: [root@bob-the-minion gluster]# mkdir test; touch test/foo [root@bob-the-minion gluster]# ln test/foo test/foo.1 [root@bob-the-minion gluster]# mv test/foo.1 test/foo [root@bob-the-minion gluster]# Verified as fixed.
Hi Kruthika, Can you please review the edited doc text for technical accuracy and sign off?
<pavithra> Previously, if a file was linked with one client and removed using another, the subsequent lookup operation from the first client would not override the cache in the absence of the unlinked name on the bricks, leading it to conclude that the file name exists. With this fix, the stale inode mapping is deleted when the lookup operation fails with the ENOENT error in the first client. </pavithra> 1) I think the first sentence should be 'Previously, if a file was linked *by* one client and removed *by* another, ...' The rest looks good to me.
Not sure how the "requires_doc_text" flag got reset with my previous update. Setting it back to '?'.
I've moved back the "requires_doc_text" to + since I've worked on it. And Krutika, I've made the change you suggested. Thank you
@Pavithra: Looks good to me.
Changing the "requires_doc_text" back to +
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2014-1853.html