I've been running some tests using File Heat and policy migration, and it doesn't seem to behave like the documents say it does. First, I was scanning my file systems using a simple policy to dump out file sizes and heat values:
Using this, I could (supposedly) see easily the most active files and how big they are. What this told me was that most of the files in the file system had a heat value of "0" every day, and that an SSD tier of 100GB would easily hold most of the active files in a 30TB file system. This seemed strange, but I'll go with it. I then created and SSD tier and ran a policy like this:
Where Plevel1 is my default data pool. This seems to run as expected, and I see files being moved to the ssd pool. However, the bulk of the IO still seems to be going to the disk (Plevel1) pool. If I look at the policy that migrates the data, I see this at execution time:
rule repack MIGRATE FROM POOL gpool TO POOL gpool WEIGHT(computeFileHeat(CURRENT_TIMESTAMP-ACCESS_TIME,xattr('gpfs.FileHeat'),KB_ALLOCATED))
Which leads me to believe that the FILE_HEAT movement is based on size as well as activity - can anyone confirm this? There is nothing comprehensive in the documentation that describes *exactly* how it all works.
Is anyone successfully using FILE_HEAT to migrate data between pools?