At the 28.07.2010 00:00, Ben Chociej wrote:
INTRODUCTION: This patch series adds experimental support for tracking data temperature in Btrfs. Essentially, this means maintaining some key stats (like number of reads/writes, last read/write time, frequency of reads/writes), then distilling those numbers down to a single "temperature" value that reflects what data is "hot." The long-term goal of these patches, as discussed in the Motivation section at the end of this message, is to enable Btrfs to perform automagic relocation of hot data to fast media like SSD. This goal has been motivated by the Project Ideas page on the Btrfs wiki. Of course, users are warned not to run this code outside of development environments. These patches are EXPERIMENTAL, and as such they might eat your data and/or memory. MOTIVATION: The overall goal of enabling hot data relocation to SSD has been motivated by the Project Ideas page on the Btrfs wiki at https://btrfs.wiki.kernel.org/index.php/Project_ideas. It is hoped that this initial patchset will eventually mature into a usable hybrid storage feature set for Btrfs. This is essentially the traditional cache argument: SSD is fast and expensive; HDD is cheap but slow. ZFS, for example, can already take advantage of SSD caching. Btrfs should also be able to take advantage of hybrid storage without any broad, sweeping changes to existing code.
Wouldn't this feature be useful for other file systems as well, so that a more general and not an only Btrfs related solution is preferable?
With Btrfs's COW approach, an external cache (where data is *moved* to SSD, rather than just cached there) makes a lot of sense. Though these patches don't enable any relocation yet, they do lay an essential foundation for enabling that functionality in the near future. We plan to roll out an additional patchset introducing some of the automatic migration functionality in the next few weeks.
With all the best Christian Stroetmann -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
