Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 952975

Summary: Files appear in stat but are lost to readdir
Product: [Community] GlusterFS Reporter: Ian Wienand <iwienand>
Component: fuseAssignee: Csaba Henk <csaba>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.3.1CC: amarts, gluster-bugs
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-25 23:59:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Logs from the client that has mounted the glusterfs volume
none
logs from client when mounted with "-o log-level=trace" for ls and stat operations none

Description Ian Wienand 2013-04-17 05:34:50 UTC 
I noticed this with a fresh glusterfs volume where i created a largish file just by dd of /dev/urandom.  I then copied the file with cp, which appeared to go fine.  However, the copy of the file does not appear to show up in readdir() (e.g. via ls)

---
[root@host03 v_swift]# ls -a
.  ..  lost+found  test.img

[root@host03 v_swift]# stat test.img2
  File: `test.img2'
  Size: 7612661760	Blocks: 14868480   IO Block: 131072 regular file
Device: 1eh/30d	Inode: 13297220110666977327  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2013-04-16 19:12:46.605984587 -0400
Modify: 2013-04-16 19:13:40.534984629 -0400
Change: 2013-04-16 19:13:40.565984629 -0400

[root@host03 v_swift]# md5sum test.img2
3d057e71ccaaf2fd5346adbe209e0734  test.img2
[root@host03 v_swift]# md5sum test.img
3d057e71ccaaf2fd5346adbe209e0734  test.img
---

this now seems to be in a state where everything seems to be missing

---
[root@host03 v_swift]# touch foobar
[root@host03 v_swift]# ls
lost+found  test.img
[root@host03 v_swift]# touch moo
[root@host03 v_swift]# ls
lost+found  test.img
[root@host03 v_swift]# ls -l foobar moo
-rw-r--r--. 1 root root 0 Apr 16 20:27 foobar
-rw-r--r--. 1 root root 0 Apr 16 20:28 moo
---

This is on a RHEL6.4 with glusterfs 3.3.1.  The volume is 

---
[root@host04 v_swift]# gluster volume info v_swift
 
Volume Name: v_swift
Type: Distributed-Replicate
Volume ID: 803c5277-6bb1-4670-b8cd-c86208037933
Status: Started
Number of Bricks: 3 x 2 = 6
Transport-type: tcp
Bricks:
Brick1: host04.internal:/data/glusterfs/v_swift/brick1
Brick2: host05.internal:/data/glusterfs/v_swift/brick1
Brick3: host06.internal:/data/glusterfs/v_swift/brick1
Brick4: host04.internal:/data/glusterfs/v_swift/brick2
Brick5: host05.internal:/data/glusterfs/v_swift/brick2
Brick6: host06.internal:/data/glusterfs/v_swift/brick2
---

The bricks are fresh ext4 file systems

I will attach some logs
Comment 1 Ian Wienand 2013-04-17 05:37:35 UTC 
Created attachment 736672 [details]
Logs from the client that has mounted the glusterfs volume
Comment 2 Ian Wienand 2013-04-17 05:49:11 UTC 
Created attachment 736675 [details]
logs from client when mounted with "-o log-level=trace" for ls and stat operations
Comment 3 Amar Tumballi 2013-04-17 06:29:28 UTC 
Looks like an issue with ext4 backend. Can you use http://review.gluster.org/4822 on top of your code, and see if its fixed? this should be fixed with 3.3.2 (and 3.4.0) release.
Comment 4 Ian Wienand 2013-04-18 03:35:05 UTC 
I tested with that patch, and it does appear to work correctly, at least for my very minimal testing, thanks
Comment 5 Ian Wienand 2013-04-25 23:59:59 UTC 
Let's mark this as a dup of that original bug mentioned in Comment #3

*** This bug has been marked as a duplicate of bug 838784 ***