Description of problem: ======================= After the file is healed, its getting promoted to hot tier. While creating 1GB file on 8+4 ec volume, brought down 4 of the bricks and bricks are up after the file is created. File got healed on the 4 bricks and saw the file in the hot tier, which should not be. Version-Release number of selected component (if applicable): ============================================================= 3.7.5-5 [root@interstellar ~]# gluster --version glusterfs 3.7.5 built on Oct 29 2015 10:11:53 Repository revision: git://git.gluster.com/glusterfs.git Copyright (c) 2006-2011 Gluster Inc. <http://www.gluster.com> GlusterFS comes with ABSOLUTELY NO WARRANTY. You may redistribute copies of GlusterFS under the terms of the GNU General Public License. [root@interstellar ~]# How reproducible: ================= 100% Steps to Reproduce: =================== As in description Actual results: ============== File getting promoted to hot tier after heal Expected results: ================= Should remain in cold tier unless read/writes done to that file from client. Internal ops should not heat the file. Additional info:
There are actually two issues here, 1) EC Selfheal traffic heats the file, as CTR Xlator is not distinguishing normal read-write FOP traffic from EC Sefheal FOP Traffic. Solution for this is detect the client-pid set in the FOP frame and ignore these FOPS in CTR Xlator. Need info from the EC dev Team, on the which client-pid EC Selfheal daemon uses to mark the FOPS different from regular FOPS. 2) During a normal write the file gets heated up for read also, which is not correct and has performance cost w.r.t the extra updates to the database. Well the reason for this is that each write that comes from the user to EC xlator converts to a read-modify-update FOPS. This read FOP doesnt have any marker on it to differentiate it from the regular read, and thus CTR tends to heat up the file. Would require a marker on this read FOP or any such internal FOPs from EC xlator.
pls post the patch details.
verified this on 3.7.5-7 and works as expected.
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