How to use SSD cache to keep HDD idle

[andrew_401]

Dear TrueNAS Community,
I've been a lurker on this forum for quite some time. However, now I would like to ask a question that I hope somebody can help me with.

For a new TrueNAS setup I would like to ask your help on how to setup a specific pool. One in which the SSD cache is used to keep the HDD's idle.

I am thinking of a pool with 3x 3T HDD and 2x 2T SSD cache (with some form of redundancy)

The use case is:
- Daily backup of photos (from phone). This backup is only sporadically accessed (once a month or less)
- 2 or 3 databases. Every minute some values are stored into these databases. Not much is logged, but the databases are quite 'large' (for me at least)
- About 500Gb of files I access regularly (multiple times a week)
- About 1 TB of files I access very sporadically (probably less than once a month)

I want to use the cache to access the HDD's less than 1 time a week and keep the HDD's in idle in the meantime.
To be clear; I do not wish to use the cache for faster read write. I want to use it to keep the HDD's in idle as long as possible.

Can anybody tell me how to setup a pool like described above? Where the SSD cache is used to keep the HDD's in idle for a long time. Is it even possible with TrueNAS?

Btw, I know the discussions about keeping the HDD's in idle and that the consensus is that you should not. But I guess that starting up a HDD approximately 52 time as year should not be any problem.

I thank you upfront for any help
Kind regards.

 

[danb35]

Can anybody tell me how to setup a pool like described above?

A pool such as you describe isn't possible in TrueNAS. You might be able to achieve the desired effect with two pools, and a weekly replication task from one to the other, but there isn't a way to do this with a single pool.

 

[awasb]

Well ... apart from the redundancy/availability aspects ...

1.) Create a mirrored SSD pool from your two SSDs. (Otherwise there wouldn't be anything like "redundancy".) -> ca. 1.5TB
2.) Create a raidz1 HDD pool. -> ca. 4.6TB
3.) Create a SSD-Backup dataset on your HDD pool.
4.) Create a replication task from your SSD pool to the SSD-Backup dataset on your HDD pool running once 1 week.
5.) Store the more frequently accessed data into datasets on your SSD pool.
6.) Share those SSD datasets.
7.) Store the less frequently accessed data (those 1TB you are accessing "probably less than once a month") into a dataset on your HDD pool.
8.) Share that HDD dataset.
9.) Think about backups.

If I were you (and just as far as I understand), I'd ditch the idea. How much energy are you going to save that way? What's the cost benefit?

I'd expect it's not going to be worth the hassle.

 

[sretalla]

You might be able to get something going with SCALE and Autotier... https://www.truenas.com/community/t...tion-i-wish-to-run-autotier.94103/post-651313

It's all experimental and I would suggest you're better off with the suggestions above, but what you're asking for is tiering (not caching as such), so I thought I's mention it.

 

[andrew_401]

Thank you all for your (very quick) replies,

I was hoping for a 'pain free' easy solution in TrueNAS but I understand that it is not possible. Still, I think it would be a nice functionality, especially for home-build servers which do see a sqewed amount of action on its stored files.

@sretalla: Thank you, I was not aware of that terminology. For 'academic' purposes I'll check out SCALE and do some searches with 'tiering'

 

[jgreco]

Still, I think it would be a nice functionality, especially for home-build servers which do see a sqewed amount of action on its stored files.

In short, redesigning ZFS is not likely to happen. ZFS was developed by Sun Microsystems who invested a fair bit in it, and what you're talking about goes to some of the underlying design assumptions in ZFS, decisions made in a slightly different era (where HDD was king), and it was designed for Sun storage arrays with lots of disks in always-on commercial/enterprise/educational environments.

A significant redesign is probably overdue, but as with many things in computer science, is unlikely to actually happen. We still use the lineal descendants of UFS (a 1970's technology) in the form of FFS (a 1980's technology) which has been tweaked with performance boosters like softupdates and noatime, but a full rip-apart and redesign of the not-horribly-complicated FFS system is unlikely because there isn't a significant driver.

ZFS probably has more drivers behind it for a redesign/reimplementation, and if there was actually sufficient funding for it, I think there's probably people who would love to do it, but the primary funding for ZFS are companies selling mass storage appliances, just like Sun Microsystems was, and I suspect that they're generally not horribly unhappy with the way the system works now.

It takes a large company with lots of resources and funding to push through things like Apple's fusion drive implementation.

There is a bit of an upside, here, though. As CPU and memory become cheaper, and SSD becomes more readily available at a reasonable price point, it becomes more realistic to take existing suboptimal tools, such as ZFS, and layer stuff on top, like Gluster or Autotier, to create these features from available components. This sort of layering has become increasingly pervasive in the industry.