Bug 952975 - Files appear in stat but are lost to readdir
Files appear in stat but are lost to readdir
Status: CLOSED DUPLICATE of bug 838784
Product: GlusterFS
Classification: Community
Component: fuse (Show other bugs)
3.3.1
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Csaba Henk
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-17 01:34 EDT by Ian Wienand
Modified: 2013-04-25 19:59 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-25 19:59:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Logs from the client that has mounted the glusterfs volume (21.88 KB, text/x-log)
2013-04-17 01:37 EDT, Ian Wienand
no flags Details
logs from client when mounted with "-o log-level=trace" for ls and stat operations (44.75 KB, text/plain)
2013-04-17 01:49 EDT, Ian Wienand
no flags Details

  None (edit)
Description Ian Wienand 2013-04-17 01:34:50 EDT
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 01:37:35 EDT
Created attachment 736672 [details]
Logs from the client that has mounted the glusterfs volume
Comment 2 Ian Wienand 2013-04-17 01:49:11 EDT
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 02:29:28 EDT
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-17 23:35:05 EDT
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 19:59:59 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.