Bug 762904 (GLUSTER-1172) - ls -lh on NFS mount of 2-mirror replicate gives incorrect file size
Summary: ls -lh on NFS mount of 2-mirror replicate gives incorrect file size
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: GLUSTER-1172
Product: GlusterFS
Classification: Community
Component: replicate
Version: nfs-alpha
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: shishir gowda
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-20 06:19 UTC by Shehjar Tikoo
Modified: 2015-12-01 16:45 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: RTP
Mount Type: nfs
Documentation: ---
CRM:
Verified Versions:

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

Description Shehjar Tikoo 2010-07-20 03:39:21 UTC 
Regression test to be done as part of http://test.gluster.com/show_bug.cgi?id=86
Comment 1 Shehjar Tikoo 2010-07-20 06:19:18 UTC 
During dd IO on a file that resides on the NFS mount point, which is in fact a replicated backend, say one replica goes down and comes back up only after dd has finished. The situation will result in an inconsistent file on one node and a consistent one on the mirror that was always up.
If we do ls -lh on the NFS mount after the dd completes and with the failed node now back up, the ls -lh returns the file size from the inconsistent replica.
Comment 2 Shehjar Tikoo 2010-09-17 05:44:20 UTC 
Setting mount type to nfs to help me keep track of bugs reported in components outside gnfs but seen over an nfs mount as compared to the fuse mount.
Comment 3 Amar Tumballi 2010-09-21 03:55:36 UTC 
issue with metadata self heal not being done properly.
Comment 4 Vijay Bellur 2010-09-29 10:34:40 UTC 
PATCH: http://patches.gluster.com/patch/5086 in master (replicate: keep read_child in inode ctx as up-to-date as possible)
Comment 5 Anand Avati 2011-02-22 07:11:23 UTC 
PATCH: http://patches.gluster.com/patch/6054 in master (replicate: set read-child to the subvolume which replied first (fastest))
Note You need to log in before you can comment on or make changes to this bug.