https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-10602 Lustre <p>File heat is a relative attribute of files/objects which reflects the access frequency of the files/objects. The file heat can be controlled by two system-level constants, time period and loss percentage. Time is divided into time periods. The access number during each time period is counted. But the file heat is only recalculated at the end of a time period. And at the end of each time period, a percentage of the former file heat is lost according to the loss percentage.</p> <p>File heat mainly designed for cache management. Cache like PCC could use file heat to determine which files to removed from the cache or which files to fetch into cache.</p> <p> </p> LU-10602

Add file heat support for Persistent Client Cache

New Feature Minor Open Unresolved Li Xi Li Xi PCC2 Mon, 5 Feb 2018 06:21:06 +0000 Sat, 30 Jan 2021 00:06:31 +0000 0 16 <p>Li Xi (lixi@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/31161" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/31161</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10602" title="Add file heat support for Persistent Client Cache" class="issue-link" data-issue-key="LU-10602">LU-10602</a> llite: add file heat support<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 98f1e3c57c695bea4b476c81da731383260dcbad</p> <p>Thanks Li Xi</p> <p>Yingjin Qian (qian@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/32969" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/32969</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10602" title="Add file heat support for Persistent Client Cache" class="issue-link" data-issue-key="LU-10602">LU-10602</a> llite: add file heat support<br/> Project: fs/lustre-release<br/> Branch: pcc<br/> Current Patch Set: 1<br/> Commit: 5765bf08fe516ee7fb63207fd374b24904bec71a</p> <p>Yingjin Qian (qian@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/32975" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/32975</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10602" title="Add file heat support for Persistent Client Cache" class="issue-link" data-issue-key="LU-10602">LU-10602</a> pcc: file heat support for PCC<br/> Project: fs/lustre-release<br/> Branch: pcc<br/> Current Patch Set: 1<br/> Commit: bfa9cd8f9323405615b7511b2bfa979243c2449e</p> <p>Yingjin Qian (qian@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/34399" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34399</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10602" title="Add file heat support for Persistent Client Cache" class="issue-link" data-issue-key="LU-10602">LU-10602</a> llite: add file heat support<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 9c9e7bf7148fb6322a1ad6451d1c0dca4f3776d1</p> <p>It would be useful to implement TopN list support for file heat.</p> <p>After an hour discussion with Yingjin and Shilong about the possible designs and their cons and pros, we think the following design might work:</p> <p>1) In order to avoid any performance impact, the sorting of the TopN will not add anything in the I/O process.</p> <p>2) TopN sorting will be implemented using binary heap based on cfs_binheap.</p> <p>3) A background thread scans "s_inodes" list of "struct super_block" and adds each inode into the binary heap. Examples of this are wait_sb_inodes(), add_dquot_ref(), drop_pagecache_sb() etc.</p> <p>4) The scanning frequency could be a configurable parameter which depends on total inode numbers, heat decay time, resolution ratio (the rate that user-space tool dumps the list), etc.</p> <p>5) Between handling of each inode, functions like cond_resched() should be called to avoid too high CPU usage or affecting normal I/O or file system access.</p> <p>6) The binary heap is reverse order, meaning the top node is the file with least heat on the top.</p> <p>7) Whenever an inode is adding to the binary heap, a new structure (e.g. "struct inode_heat_node") will be allocated for the inode with FIDs, inums and other fields properly set.</p> <p>8) If the size of binary heap becomes larger than N (i.e. size == N+1) after inserting, an inodes will be removed from the top of the binary heap.</p> <p>9) <b>optimization:</b> cfs_binheap_copy() will be implemented to copy the binary heap. When a user-space process starts to dump the TopN list, the binary heap will be copied so as to make the dumping quicker. cfs_binheap_copy() essentially copies element arrays, thus should be fast.</p> <p>10) When user-space tool starts to dump the TopN list, the dumping binary heap shall be removed from the top to generate the TopN list with ascending order. The user-space tool shall change the list to descending order if needed.</p> <p>11) Before dumping the TopN list, the administrator should configure which type of file heats (read, write, read sample or write sample) the sorting should be based on. N should also be a configurable parameter. These things could be configured through /sys or /proc interface. If memory is not a limitation, we could maitain four topN list at the same time for each type of file heats.</p> <p>12) User-space tool shall read the TopN list and show in a proper way flushing the result after each time period (like what command top does).</p> <p>Maybe cfs_binheap_() supports removing from the tail (not the top). Then the binary heap could be implemented as descending order, i.e. the top node has the highest heap.</p> <p>The command to show the TopN heat can be defined as follow:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> # lfs heat_top [-p $sample_period] [-i $heat_dimension] [-N $topN]</pre> </div></div> <p>Where<br/> -<em>$sample_period</em> is the period in second to show the topN heat;<br/> -<em>$heat_dimension</em> is the key value to sort the file heat. Currently Lustre file heat has 4 dimension indicators to measure the file heat: readsample, writesample, readbyte, writebyte. The $heat_dimension could be "readsample", "writesample", "readbyte", "writebyte", or even their combination such "iosample" (it means "readsample" heat value + "writesample" heat value) or "iobyte" (it means sorting according to the key "readbyte" heat value + "writesample" heat value).<br/> -<em>$topN</em> is the topn value.</p> <p>We also should implement a llapi interface for users to get the TopN file heat value via IOCTL, it could be defined as:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> struct lu_heat_item { struct lu_fid lhi_fid; struct lu_heat lhi_heat; }; struct lu_topn_heats { __u32 lth_topn; struct lu_heat_item lth_item[0]; };</pre> </div></div> <p> </p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"> <span class="code-object">int</span> llapi_heat_topn_get(<span class="code-keyword">const</span> <span class="code-object">char</span> *mntpt, <span class="code-object">int</span> topn, <span class="code-object">char</span> *sortkey, sturct lu_topn_heats *heats);</pre> </div></div> <p>Each time, an adminstrator wants to get the topN file heat information, it can call the llapi above.<br/> As there are so many sorting factors (we have illustrate 6 sort keys above) and the TopN is also a variable,to simply the implementation, IMHO, we would better to avoid to use a background kernel thread, just need to scan the "s_inodes" list of "superblock" and sort the file heat when the user calls the llapi via IOCTL above in the first version implementation.</p> <p>&gt; IMHO, we would better to avoid to use a background kernel thread, just need to scan the "s_inodes" list of "superblock" and sort the file heat when the user calls the llapi via IOCTL above in the first version implementation.</p> <p>Sounds reasonable, Yingjin. This would make the implementation simpler.</p> <p>Yingjin Qian (qian@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/34540" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34540</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10602" title="Add file heat support for Persistent Client Cache" class="issue-link" data-issue-key="LU-10602">LU-10602</a> llite: Add support for file heat TopN listing<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 219ca7222ae12ebf7a1e0bf48adbf199fe041b82</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/34399/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34399/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10602" title="Add file heat support for Persistent Client Cache" class="issue-link" data-issue-key="LU-10602">LU-10602</a> llite: add file heat support<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: ae723cf8161f7af15fb7c2541fa7d4131a816af9</p> <p>Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/34757" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34757</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10602" title="Add file heat support for Persistent Client Cache" class="issue-link" data-issue-key="LU-10602">LU-10602</a> utils: fix file heat support<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 6a9db0937c5c4ae526d250aff7d11c83fb22bfd0</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/34757/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/34757/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-10602" title="Add file heat support for Persistent Client Cache" class="issue-link" data-issue-key="LU-10602">LU-10602</a> utils: fix file heat support<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: ac1f97a881019b78ce3289885461259d280562b3</p> Blocker Related LU-10530 LU-10092 LU-10499 Development Rank 1|hzzs4v: Rank (Obsolete) 9223372036854775807