Bug 1278754 - Data Tiering:Metadata changes to a file should not heat/promote the file
Data Tiering:Metadata changes to a file should not heat/promote the file
Status: CLOSED ERRATA
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: tier (Show other bugs)
3.1
Unspecified Unspecified
urgent Severity urgent
: ---
: RHGS 3.1.2
Assigned To: Joseph Elwin Fernandes
nchilaka
: ZStream
Depends On:
Blocks: 1260783 1260923 1279166 1282315
  Show dependency treegraph
 
Reported: 2015-11-06 06:06 EST by nchilaka
Modified: 2016-09-17 11:36 EDT (History)
6 users (show)

See Also:
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 00:53:31 EST
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)
qe verification log (205.54 KB, text/plain)
2015-11-25 05:26 EST, nchilaka
no flags Details

  None (edit)
Description nchilaka 2015-11-06 06:06:17 EST
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 nchilaka 2015-11-25 05:23:17 EST
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 nchilaka 2015-11-25 05:26 EST
Created attachment 1098682 [details]
qe verification log
Comment 6 errata-xmlrpc 2016-03-01 00:53:31 EST
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

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