Details
-
New Feature
-
Resolution: Unresolved
-
Minor
-
None
-
None
-
9223372036854775807
Description
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.
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.
Attachments
Issue Links
Activity
Oleg Drokin (green@whamcloud.com) merged in patch https://review.whamcloud.com/34399/
Subject: LU-10602 llite: add file heat support
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: ae723cf8161f7af15fb7c2541fa7d4131a816af9
Yingjin Qian (qian@ddn.com) uploaded a new patch: https://review.whamcloud.com/34540
Subject: LU-10602 llite: Add support for file heat TopN listing
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 219ca7222ae12ebf7a1e0bf48adbf199fe041b82
> 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.
Sounds reasonable, Yingjin. This would make the implementation simpler.
The command to show the TopN heat can be defined as follow:
# lfs heat_top [-p $sample_period] [-i $heat_dimension] [-N $topN]
Where
-$sample_period is the period in second to show the topN heat;
-$heat_dimension 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).
-$topN is the topn value.
We also should implement a llapi interface for users to get the TopN file heat value via IOCTL, it could be defined as:
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];
};
int llapi_heat_topn_get(const char *mntpt, int topn, char *sortkey, sturct lu_topn_heats *heats);
Each time, an adminstrator wants to get the topN file heat information, it can call the llapi above.
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.
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.
It would be useful to implement TopN list support for file heat.
After an hour discussion with Yingjin and Shilong about the possible designs and their cons and pros, we think the following design might work:
1) In order to avoid any performance impact, the sorting of the TopN will not add anything in the I/O process.
2) TopN sorting will be implemented using binary heap based on cfs_binheap.
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.
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.
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.
6) The binary heap is reverse order, meaning the top node is the file with least heat on the top.
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.
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.
9) optimization: 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.
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.
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.
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).
Yingjin Qian (qian@ddn.com) uploaded a new patch: https://review.whamcloud.com/34399
Subject: LU-10602 llite: add file heat support
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 9c9e7bf7148fb6322a1ad6451d1c0dca4f3776d1
Yingjin Qian (qian@ddn.com) uploaded a new patch: https://review.whamcloud.com/32975
Subject: LU-10602 pcc: file heat support for PCC
Project: fs/lustre-release
Branch: pcc
Current Patch Set: 1
Commit: bfa9cd8f9323405615b7511b2bfa979243c2449e
Yingjin Qian (qian@ddn.com) uploaded a new patch: https://review.whamcloud.com/32969
Subject: LU-10602 llite: add file heat support
Project: fs/lustre-release
Branch: pcc
Current Patch Set: 1
Commit: 5765bf08fe516ee7fb63207fd374b24904bec71a
Andreas Dilger (adilger@whamcloud.com) uploaded a new patch: https://review.whamcloud.com/34757
Subject: LU-10602 utils: fix file heat support
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 6a9db0937c5c4ae526d250aff7d11c83fb22bfd0