ZFS is not going to support traditional promotion of hot data to a SSD pool anytime soon, and I currently am not aware of any current viable effort to implement this. To do this you’d basically set up an SSD and HDD pool, and use something like bcache over top of them. Or the reverse
As an alternative that has worked great for me, if you have special vdevs made of (mirrored) SSDs that are 500GB-1TB in size, you can basically set special_small_blocks to 64K across the pool to put both metadata and your worst performing data on the SSDs instead of the HDDs (after redoing the pool/moving the data first, since it will only apply to new data written) automatically without worrying about space until you have a ridiculous amount of data (tens of TB’s) or special storage needs. This is why I greatly prefer regular flash special vdevs over using optane due to capcity/cost vs benefit gained. When implementing special vdevs, I recommend backing up and remaking the pool from scratch with special vdevs from the beginning, in order to prevent strange problems.
special_small_blocks can currently be set to 1M (at least I’m pretty sure, never tested it. Previously it was limited to 128K), but you’ll need to adjust the recordsize on the datasets to be higher than whatever the special_small_blocks is for that dataset. Otherwise it’ll all go to the special vdev.
If you need a particular set of data accelerated in it’s entirety, put it on a dataset, and set the special_small_blocks to match the recordsize of that particular dataset.
This allows you to send/recv or otherwise manage your pools without having to worry about what data is where.
Eventually I think bcachefs will satisfy most of the desires of advanced linux users once it matures. That’s a ways off yet, but it’s something to watch.