Bug 1331263

Summary: SAMBA+TIER : File size is not getting updated when created on windows samba share mount
Product: [Community] GlusterFS Reporter: Mohammed Rafi KC <rkavunga>
Component: tieringAssignee: Mohammed Rafi KC <rkavunga>
Status: CLOSED CURRENTRELEASE QA Contact: bugs <bugs>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.7.11CC: bugs, kramdoss, nchilaka, rcyriac, rhinduja, rhs-smb, rjoseph, rkavunga, sankarshan, sashinde, vdas
Target Milestone: ---Keywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glusterfs-3.7.12 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1330567 Environment:
Last Closed: 2016-06-28 12:15:37 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:
Bug Depends On: 1322247, 1330567    
Bug Blocks:    

Description Mohammed Rafi KC 2016-04-28 07:20:15 UTC
+++ 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)

Comment 1 Vijay Bellur 2016-04-29 06:08:11 UTC
REVIEW: http://review.gluster.org/14109 (gfapi: fill iatt in readdirp_cbk if entry->inode is null) posted (#1) for review on release-3.7 by mohammed rafi  kc (rkavunga)

Comment 2 Vijay Bellur 2016-05-24 05:48:36 UTC
COMMIT: http://review.gluster.org/14109 committed in release-3.7 by Rajesh Joseph (rjoseph) 
------
commit 1d52eae8532e027a97dd947b3889b38abe0c113c
Author: Mohammed Rafi KC <rkavunga>
Date:   Tue Apr 26 16:59:30 2016 +0530

    gfapi: fill iatt in readdirp_cbk if entry->inode is null
    
    If any of dirent have inode as null in readdirp_cbk, which indicates
    that the stat information is not valid. So for such entries, we send
    explicit lookup to fill the stat information.
    
    Backport of>
    >Change-Id: I0604bce34583db0bb04b5aae8933766201c6ddad
    >BUG: 1330567
    >Signed-off-by: Mohammed Rafi KC <rkavunga>
    >Reviewed-on: http://review.gluster.org/14079
    >NetBSD-regression: NetBSD Build System <jenkins.org>
    >Smoke: Gluster Build System <jenkins.com>
    >CentOS-regression: Gluster Build System <jenkins.com>
    >Reviewed-by: Niels de Vos <ndevos>
    
    (cherry picked from commit 9423bdeed169076ebedd9af40b52aaac58c9839e)
    
    Change-Id: I90a218c78d5544a3b49b29079c64a8b76e7939df
    BUG: 1331263
    Signed-off-by: Mohammed Rafi KC <rkavunga>
    Reviewed-on: http://review.gluster.org/14109
    Smoke: Gluster Build System <jenkins.com>
    CentOS-regression: Gluster Build System <jenkins.com>
    NetBSD-regression: NetBSD Build System <jenkins.org>
    Reviewed-by: Rajesh Joseph <rjoseph>

Comment 3 Kaushal 2016-06-28 12:15:37 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.7.12, please open a new bug report.

glusterfs-3.7.12 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] https://www.gluster.org/pipermail/gluster-devel/2016-June/049918.html
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user