[Bugs] [Bug 1331263] New: SAMBA+TIER : File size is not getting updated when created on windows samba share mount
bugzilla at redhat.com
bugzilla at redhat.com
Thu Apr 28 07:20:15 UTC 2016
https://bugzilla.redhat.com/show_bug.cgi?id=1331263
Bug ID: 1331263
Summary: SAMBA+TIER : File size is not getting updated when
created on windows samba share mount
Product: GlusterFS
Version: 3.7.11
Component: tiering
Keywords: ZStream
Severity: high
Assignee: bugs at gluster.org
Reporter: rkavunga at redhat.com
QA Contact: bugs at gluster.org
CC: bugs at gluster.org, josferna at redhat.com,
kramdoss at redhat.com, nchilaka at redhat.com,
rcyriac at redhat.com, rhinduja at redhat.com,
rhs-smb at redhat.com, rkavunga at redhat.com,
sashinde at redhat.com, vdas at redhat.com
Depends On: 1322247, 1330567
+++ This bug was initially created as a clone of Bug #1330567 +++
+++ This bug was initially created as a clone of Bug #1322247 +++
Description of problem:
On a windows client when a tiered volume is mounted and microsoft office files
are created with some data in it, the size of the file is still remains 0KB.
For a distribute volume it reflects the actual size for the same files.
Even on "cifs" & "fuse" the actual size is reflecting.
Version-Release number of selected component (if applicable):
mainline
How reproducible:
Always
Steps to Reproduce:
1.Mount a tier volume (cold tier : Distributed-Disperse | 2 x (8 + 4) | Hot
Tier Type : Distributed-Replicate 4 x 2 = 8) on windows client
2. Create docx files with data in it.
3.do ls in smbclient
Actual results:
File size is 0KB
Expected results:
Actual size should reflect
Additional info:
--- Additional comment from Vivek Das on 2016-03-30 03:00:20 EDT ---
--- Additional comment from Mohammed Rafi KC on 2016-04-15 10:27:18 EDT ---
Myself together with Anoop CS reproduced the issue using both windows machine
and smbclient
set-up details : gluster - upstream master
samba - 4.4
The problem turned out to be the same problem with T file issue in tiering
which is described in #bug 1303298 .
RCA:
For tiered volume , we send readdirp only to cold tier for performance
improvement and other functional issues. Since cold tier is the default hashed
subvol, every file or corresponding linkfile should be there in cold tier. For
files in hot tier, there will be a linkfile and readdirp from cold tier for
such files will not have proper attributes. In normal client stack, tier
xlators will set inode=null for such entries to force a lookup in case of fuse
mount and for nfs , we will set a flag to let nfs client know about such an
entry as a stale.
In case of samba client, They will just print what they got, means the stat
will have only sticky bit set.
More details:
We brought this fix to increase the readdir performance and to fix an issue
which can potentially result in data loss (#bug 1278384). So reverting the
changes will result in performance drop in readdir and we need additional
patch to solve the issue in #bug 1278384.
Otherwise we can fix this problem from gf_api layer or from tier layer by doing
a stat to hot tier for entries in hot tier, which will also give a worst
performance if there are two or more entries in hot tier. We can reduce the
performance drop by introducing bulk lookup (one lookup for all entries since
files can be either in hot or cold).
Or otherwise if there is any way to let samba client about a stale entry in a
readdirp, we could try that also, so that samba can do a stat before printing
it.
--- Additional comment from Vijay Bellur on 2016-04-26 09:28:44 EDT ---
REVIEW: http://review.gluster.org/14079 (gf_api: fill iatt in readdirp_cbk if
entry->inode is null;) posted (#1) for review on master by mohammed rafi kc
(rkavunga at redhat.com)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1322247
[Bug 1322247] SAMBA+TIER : File size is not getting updated when created on
windows samba share mount
https://bugzilla.redhat.com/show_bug.cgi?id=1330567
[Bug 1330567] SAMBA+TIER : File size is not getting updated when created on
windows samba share mount
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
More information about the Bugs
mailing list