It is not a write through cache. The drive firmware copies frequently read files to flash.
The problem with that claim is that it doesn't jive with it being OS-agnostic. To know what a file are, you have to understand the file system. I can guarantee you that this drive does not understand XFS with external journal, which is what I use.
If you mean frequently read blocks, that's doable, but to have a counter for every block of a 2TB drive would take up far more memory than this device has.
What is feasible is a caching system which expires blocks that haven't been read in a certain amount of time. But that would contradict the claim that it boosts boot speed, because those blocks are generally only read once, at boot time, and would get expunged.
It doesn't have to track every block on the drive, only those it has seen. And it wouldn't need a counter to each block, a simple seen/not-seen is enough. The controller could use an algorithm like:
1. Block first seen - Mark the block address in some list of seen blocks.
2. Block seen list full - Drop the LRU seen block from the list.
3. Block seen again - If the block is in the list of seen blocks, migrate the block contents to the cache.
4. Not enough cache space, evict the LRU block in the cache.
The block seen list need only be maintained in controller memory, to save wear and tear on FLASH, with the FLASH reserved for cached block data and meta-data.
Optimisations could be in place to spot things like sequential reads (which may not benefit from caching) and implementing write back caching for already cached blocks.
But this'd all be OS and FS agnostic.