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
Created attachment 736672 [details] Logs from the client that has mounted the glusterfs volume
Created attachment 736675 [details] logs from client when mounted with "-o log-level=trace" for ls and stat operations
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.
I tested with that patch, and it does appear to work correctly, at least for my very minimal testing, thanks
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 ***