Bug 857336

Summary: DHT- able to create two files with same filename at same level
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Rachana Patel <racpatel>
Component: glusterfsAssignee: Amar Tumballi <amarts>
Status: CLOSED NOTABUG QA Contact: amainkar
Severity: medium Docs Contact:
Priority: unspecified    
Version: 2.0CC: aavati, bfoster, rhs-bugs, vbellur, vraman
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: 2012-10-04 00:38:08 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
mnt-log none

Description Rachana Patel 2012-09-14 07:06:41 UTC
Description of problem:
DHT- able to create two files with same filename at same level

Version-Release number of selected component (if applicable):
3.3.0rhs-28.el6rhs.x86_64

How reproducible:
not always

Steps to Reproduce:
1. Create a Distributed volume having 3 or more sub-volumes on multiple server and start that volume.


2. Fuse Mount the volume from the client-1 using “mount -t glusterfs  server:/<volume> <client-1_mount_point>”

3. From mount point create some dirs and files inside it.

  
Actual results:
At one point of time was able to create two files with same name at same level

Expected results:
two files should not have same name at same leve;

Additional info:

[root@Rhs1 ~]# gluster volume status test
Status of volume: test
Gluster process						Port	Online	Pid
------------------------------------------------------------------------------
Brick 10.70.35.81:/home/test/1				24013	Y	6447
Brick 10.70.35.85:/home/test/1				24009	Y	2540
Brick 10.70.35.86:/home/test/1				24009	Y	4488
NFS Server on localhost					38467	Y	8320
NFS Server on 10.70.35.85				38467	Y	4376
NFS Server on 10.70.35.86				38467	Y	4494

From mount point
[root@client d1]# ls -li
total 47
13457337320920020457 -rw-r--r--. 1 root root     0 Sep 13 12:59 f{1..10}
 9986897158949792342 -rw-r--r--. 1 root root     8 Sep 13 16:31 file1
10788711374164874802 -rw-r--r--. 1 root root  1406 Sep 13 12:59 file1 
10201008087566570220 -rw-r--r--. 1 root root    28 Sep 13 16:49 file2
13727813557709485795 -rw-r--r--. 1 root root   819 Sep 13 13:00 file2 
12153990574000815460 -rw-r--r--. 1 root root 43591 Sep 13 13:01 file3 

[root@client d1]# stat file1
  File: `file1'
  Size: 8         	Blocks: 1          IO Block: 131072 regular file
Device: 16h/22d	Inode: 9986897158949792342  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-09-13 16:31:23.301796025 +0530
Modify: 2012-09-13 16:31:17.419576226 +0530
Change: 2012-09-13 16:31:17.419576226 +0530

[root@client d1]# stat file2
  File: `file2'
  Size: 28        	Blocks: 1          IO Block: 131072 regular file
Device: 16h/22d	Inode: 10201008087566570220  Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-09-13 16:49:10.050576107 +0530
Modify: 2012-09-13 16:49:04.332754684 +0530
Change: 2012-09-13 16:49:04.332754684 +0530


#############

Third sub-vol

[root@Rhs3 1]# ls -li /home/test/1/d1
total 48
402653333 -rw-r--r--. 2 root root     0 Sep 13 12:59 f{1..10}
402653343 -rw-r--r--. 2 root root   819 Sep 13 13:00 file2 
402653350 -rw-r--r--. 2 root root 43591 Sep 13 13:01 file3 

[root@Rhs3 1]# stat /home/test/1/d1/file2
stat: cannot stat `/home/test/1/d1/file2': No such file or directory

############

First sub-vol

[root@Rhs1 ~]# ls -li /home/test/1/d1
total 12
269820356 -rw-r--r--. 2 root root    8 Sep 13 16:31 file1
268610978 -rw-r--r--. 2 root root 1406 Sep 13 12:59 file1 
268833954 -rw-r--r--. 2 root root   28 Sep 13 16:49 file2

[root@Rhs1 ~]# stat  /home/test/1/d1/file1
  File: `/home/test/1/d1/file1'
  Size: 8         	Blocks: 8          IO Block: 4096   regular file
Device: fc05h/64517d	Inode: 269820356   Links: 2
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-09-13 16:31:23.301796025 +0530
Modify: 2012-09-13 16:31:17.419576226 +0530
Change: 2012-09-13 16:31:17.419576226 +0530

[root@Rhs1 ~]# stat  /home/test/1/d1/file2
  File: `/home/test/1/d1/file2'
  Size: 28        	Blocks: 8          IO Block: 4096   regular file
Device: fc05h/64517d	Inode: 268833954   Links: 2
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2012-09-13 16:49:10.050576107 +0530
Modify: 2012-09-13 16:49:04.332754684 +0530
Change: 2012-09-13 16:49:04.332754684 +0530

Comment 1 Rachana Patel 2012-09-14 07:09:01 UTC
Created attachment 612744 [details]
mnt-log

Comment 3 shishir gowda 2012-09-26 07:15:04 UTC
Looks like an issue with the backend fs, as the file is created twice under the same directory, with different inode numbers.

[root@Rhs1 ~]# ls -li /home/test/1/d1
total 12
269820356 -rw-r--r--. 2 root root    8 Sep 13 16:31 file1
268610978 -rw-r--r--. 2 root root 1406 Sep 13 12:59 file1 
268833954 -rw-r--r--. 2 root root   28 Sep 13 16:49 file2

Comment 4 Amar Tumballi 2012-09-27 11:55:58 UTC
need xfs_metadump output i guess. Need help from filesystem team if the backend filesystem has duplicate files.

Comment 5 Anand Avati 2012-10-03 18:23:40 UTC
Are you sure things are not fooling the eye here, that the first "file1" is actually "file1 " (with extra space at the end), or the other way maybe?

Comment 6 Anand Avati 2012-10-04 00:38:08 UTC
Actually now I'm quite certain that this is a non-bug entirely.

Firstly - If there indeed were two "file1", I'm wondering how promptly the first lstat("file1") gave attributes and inode number of the first file1 and second lstat("file1") (which is absolutely indistinguishable from the first call) gave different attributes and inode number.


Secondly - The "second" file1, having size 1406 has an extra space in the end. It is actually "file1 ". I could verify this by "double clicking" the white space to the right of the filenames where the browser highlights "empty space". The width of the highlighted "empty space" is equal for the first file1 and file2, but the second "file 2" has a less wider highlighted "empty space" (because of the presence of a valid space at the end).

Asking for help from the filesystem team is surely going to be quite embarrassing :-)