<font size=2 face="sans-serif">fileHeatLossPercent=10, fileHeatPeriodMinutes=1440</font><br><br><font size=2 face="sans-serif">means any file that has not been accessed
for 1440 minutes (24 hours = 1 day) will lose 10% of its Heat.</font><br><br><font size=2 face="sans-serif">So if it's heat was X at noon today,
tomorrow 0.90 X, the next day 0.81X, on the k'th day
(.90)**k * X.</font><br><font size=2 face="sans-serif">After 63 fileHeatPeriods, we always
round down and compute file heat as 0.0.</font><br><br><font size=2 face="sans-serif">The computation (in floating point with
some approximations) is done "on demand" based on a heat value
stored in the Inode the last time the unix access "atime" and
the current time. So the cost of maintaining FILE_HEAT for a file
is some bit twiddling, but only when the file is accessed and the atime
would be updated in the inode anyway.<br></font><br><font size=2 face="sans-serif">File heat increases by approximately
1.0 each time the entire file is read from disk. This is done proportionately
so if you read in half of the blocks the increase is 0.5.</font><br><font size=2 face="sans-serif">If you read all the blocks twice FROM
DISK the file heat is increased by 2. And so on. But only IOPs are
charged. If you repeatedly do posix read()s but the data is in cache,
no heat is added.</font><br><br><br><font size=2 face="sans-serif">The easiest way to observe FILE_HEAT
is with the mmapplypolicy directory -I test -L 2 -P fileheatrule.policy</font><br><br><font size=2 face="sans-serif">RULE 'fileheatrule' LIST 'hot' SHOW('Heat='
|| varchar(FILE_HEAT)) /* in file fileheatfule.policy */</font><br><br><font size=2 face="sans-serif">Because policy reads metadata from inodes
as stored on disk, when experimenting/testing you may need to </font><br><br><font size=2 face="sans-serif">mmfsctl fs suspend-write; mmfsctl
fs resume</font><br><br><font size=2 face="sans-serif">to see results immediately.</font><br><br><br><br><br><br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">Andreas Landhuer
<alandhae@gmx.de></font><br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">gpfsug-discuss@spectrumscale.org</font><br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">09/26/2016 08:12 AM</font><br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">[gpfsug-discuss]
File_heat for GPFS File Systems Questions over Questions
...</font><br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br><hr noshade><br><br><br><tt><font size=2><br>Hello GPFS experts,<br><br>customer wanting a report about the usage of the usage including file_heat
<br>in a large Filesystem. The report should be taken every month.<br><br>mmchconfig fileHeatLossPercent=10,fileHeatPeriodMinutes=30240 -i<br><br>fileHeatPeriodMinutes=30240 equals to 21 days.<br>I#m wondering about the behavior of fileHeatLossPercent.<br><br>- If it is set to 10, will file_heat decrease from 1 to 0 in 10 steps?<br>- Or does file_heat have an asymptotic behavior, and heat 0 will never
be <br>reached?<br><br>Anyways the results will be similar ;-) latter taking longer.<br><br>We want to achieve following file lists:<br><br>- File_Heat > 50% -> rather hot data<br>- File_Heat 50% < x < 20 -> lukewarm data<br>- File_Heat 20% <= x <= 0% -> ice cold data<br><br>We will have to work on the limits between the File_Heat classes, <br>depending on customers wishes.<br><br>Are there better parameter settings for achieving this?<br><br>Do any scripts/programs exist for analyzing the file_heat data?<br><br>We have observed when taking policy runs on a large GPFS file system, the
<br>meta data performance significantly dropped, until job was finished.<br>It took about 15 minutes on a 880 TB with 150 Mio entries GPFS file system.<br><br>How is the behavior, when file_heat is being switched on?<br>Do all files in the GPFS have the same temperature?<br><br>Thanks for your help<br><br> Ciao<br><br> Andreas<br><br>-- <br>Andreas Landhuer
+49 151 12133027 (mobile)<br>alandhae@gmx.de<br>_______________________________________________<br>gpfsug-discuss mailing list<br>gpfsug-discuss at spectrumscale.org<br></font></tt><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss"><tt><font size=2>http://gpfsug.org/mailman/listinfo/gpfsug-discuss</font></tt></a><tt><font size=2><br></font></tt><br><BR>