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
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 =====================
Created attachment 1098682 [details] qe verification log
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