Bug 765563 (GLUSTER-3831) - ENOENT when Node replaced by another machine
Summary: ENOENT when Node replaced by another machine
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: GLUSTER-3831
Product: GlusterFS
Classification: Community
Component: protocol
Version: 3.2.4
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Amar Tumballi
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 854633
TreeView+ depends on / blocked
 
Reported: 2011-11-28 12:22 UTC by Anush Shetty
Modified: 2013-12-19 00:07 UTC (History)
2 users (show)

Fixed In Version: glusterfs-3.4.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 854633 (view as bug list)
Environment:
Last Closed: 2013-07-24 17:14:08 UTC
Regression: RTP
Mount Type: fuse
Documentation: ---
CRM:
Verified Versions:

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Description Anush Shetty 2011-11-28 12:22:06 UTC 
From gluster-devel mailing list

After machine2 replaced the node, machine1 gets the new inode number using READDIR, but the inode number returned by LOOKUP is the one for the deleted node. The only way to work it around is to unmount and remount the filesystem.

machine1# cd /gfs/stale && ls -l
total 4
drwxr-xr-x  2 root  wheel  2048 Nov 27 06:47 a

machine2# cd /gfs/stale && cp -r a b && rm -Rf a && mv b a

machine1# ls -l 
ls: a: No such file or directory
machine1# cd a
machine1# ls
ls: .: No such file or directory
machine1# cd /gfs/stale 
machine1# ls -l
ls: a: No such file or directory
Comment 1 Amar Tumballi 2011-12-01 07:38:40 UTC 
Is this tried to reproduce? I see that fuse-bridge already has a mechanism to re-validate the inodes.

Please try to reproduce on master branch, and confirm the behavior.
Comment 2 Amar Tumballi 2012-12-24 09:25:17 UTC 
not seen in master branch now (after an year of bug report), please test with 3.4.0qa series and see if it happens again.
Note You need to log in before you can comment on or make changes to this bug.