Bug 857336 - DHT- able to create two files with same filename at same level
DHT- able to create two files with same filename at same level
Status: CLOSED NOTABUG
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: glusterfs (Show other bugs)
2.0
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Amar Tumballi
amainkar
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-14 03:06 EDT by Rachana Patel
Modified: 2015-04-20 07:57 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-10-03 20:38:08 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)
mnt-log (36.53 KB, application/x-gzip)
2012-09-14 03:09 EDT, Rachana Patel
no flags Details

  None (edit)
Description Rachana Patel 2012-09-14 03:06:41 EDT
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 03:09:01 EDT
Created attachment 612744 [details]
mnt-log
Comment 3 shishir gowda 2012-09-26 03:15:04 EDT
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 07:55:58 EDT
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 14:23:40 EDT
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-03 20:38:08 EDT
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 :-)

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