Bug 1278754

Summary: Data Tiering:Metadata changes to a file should not heat/promote the file
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Nag Pavan Chilakam <nchilaka>
Component: tierAssignee: Joseph Elwin Fernandes <josferna>
Status: CLOSED ERRATA QA Contact: Nag Pavan Chilakam <nchilaka>
Severity: urgent Docs Contact:
Priority: urgent    
Version: rhgs-3.1CC: asrivast, dlambrig, rcyriac, rhs-bugs, sankarshan, storage-qa-internal
Target Milestone: ---Keywords: ZStream
Target Release: RHGS 3.1.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glusterfs-3.7.5-7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1279166 (view as bug list) Environment:
Last Closed: 2016-03-01 05:53:31 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:    
Bug Blocks: 1260783, 1260923, 1279166, 1282315    
Attachments:
Description Flags
qe verification log none

Description Nag Pavan Chilakam 2015-11-06 11:06:17 UTC
Description of problem:
======================
Currently we are heating the file and promoting a file if chnages are made to the metadata of the file, eg chnaging file permission, changing times,etc
This is actually a tiering feature and heating files for metadata changes is not the right thing to do.
Only data read or writes should promote files. 
metadata read/changes must not promote a file


Version-Release number of selected component (if applicable):
================================================================
[root@zod ~]# rpm -qa|grep gluster
glusterfs-libs-3.7.5-5.el7rhgs.x86_64
glusterfs-fuse-3.7.5-5.el7rhgs.x86_64
glusterfs-3.7.5-5.el7rhgs.x86_64
glusterfs-server-3.7.5-5.el7rhgs.x86_64
glusterfs-client-xlators-3.7.5-5.el7rhgs.x86_64
glusterfs-cli-3.7.5-5.el7rhgs.x86_64
glusterfs-api-3.7.5-5.el7rhgs.x86_64
glusterfs-debuginfo-3.7.5-5.el7rhgs.x86_64


How reproducible:
====================
always

Steps to Reproduce:
=================
1.create a volume and have some files
2.now attach tier and turn on ctr
3.now make some metadata changes to  the file like, changing permission of the cold files or touch the file to change the atime/ctime/mtime of the file


Actual results:
===============
it can be seen that these Ops heat the file

Expected results:
==================
we should not be heating files when metadata changes, as this is not the real use case of tiering. Tiering is to promote files where data changes are happening frequently so that users can make those read/writes faster

Comment 3 Nag Pavan Chilakam 2015-11-25 10:23:17 UTC
Ran the following cases on glusterfs-3.7.5-7 build.
1)In cache mode:
> for files in cold tier(legacy)made modifications to file permissions, times like atime to see if the file was getting heated. Files were not getting heated with any of the metadata changes as the db was not anyway increasing the counts. Hence files were not getting promoted
>for files in hot tier, even if they are being any metadata changes as above, files are getting demoted when no file data access happens
2)in test mode:
>made modifications to file permissions, times like atime to see if the file was getting heated. Files were not getting heated with any of the metadata changes as the db was not anyway increasing the counts
>for files in hot tier, even if they are being any metadata changes as above, files are getting demoted when no file data access happens

Turned on counters and set the read and write threshold to 2, file metadata opertaions were not increasing the count.


Hence working as expected. Moving the bug to verified:


Logs are attached

=====================

Comment 4 Nag Pavan Chilakam 2015-11-25 10:26:19 UTC
Created attachment 1098682 [details]
qe verification log

Comment 6 errata-xmlrpc 2016-03-01 05:53:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0193.html