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: | glusterfs | Assignee: | Amar Tumballi <amarts> | ||||
Status: | CLOSED NOTABUG | QA Contact: | amainkar | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 2.0 | CC: | 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
Rachana Patel
2012-09-14 07:06:41 UTC
Created attachment 612744 [details]
mnt-log
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 need xfs_metadump output i guess. Need help from filesystem team if the backend filesystem has duplicate files. 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? 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 :-) |