I've often wondered why there aren't any (that I'm aware of anyway) Linux hierarchical storage managers (HSM). I realize they are typically used in big iron with things like tape as the base level of storage, but especially when it looked like Optane was going to be a thing it seemed like spinning<->SSD<->Optane<->RAM could be a huge performance opportunity. Though, I guess that's a "layering violation"... Honestly, at this point we've gone almost entirely SSD except for our ZFS backup servers, and that layering violation already has an SSD and RAM cache in it...

▲

uniqueuid an hour ago | parent | next [-]

When you're running ZFS (or probably some other clever layering violation like bcachefs) on heterogeneous workloads, you will quickly run into the limits of built-in assumptions. At least that's my experience:

- ARC may require manual tuning for size and metadata size to accommodate page cache, in-app caches, file count etc

- L2ARC and SLOGs are very obviously useful for some clear workloads, but have some cliffs you don't expect, such as ram required for L2ARC mapping, unexpected cold/hot/boot behavior

- Reasoning about reliability becomes harder the more tiers you have

Just imagine, to pick a simple example, you're running postgres, thousands of sqlite3 dbs and one huge duckdb (larger-than-ram) on a single such system - it would perhaps manage to adapt to one such workload at a time, but would it balance all three at the same time?

So much as I'd love to see this direction, I can also imagine the pains coming with it.

▲

bilegeek an hour ago | parent | next [-]

The best solution is metadata-only caching, as that's mostly random I/O and would leave the mechanical bandwidth fully for the data itself. The downside is that L2ARC won't have everything, as it isn't proactive; there is the special device, but then the metadata is SSD-only, with that one failure point unless you run mirrors.

If they'd get around to merging Special Failsafe [1] and hybrid drives could address the flash space separately like under SAS, it would be a no-brainer.

[1]https://github.com/openzfs/zfs/pull/16185

	▲	an hour ago \| parent [-]
		[deleted]

▲

ssl-3 30 minutes ago | parent | prev [-]

Right now at the ZFS-using desktop PC I write this with:

640GB of total L2ARC, 66% utilized (34% available). 664MB of RAM is used to keep track of this.

The machine only has an uptime of a little over a week right now, but over that period L2ARC had a 93% hit rate.

L2ARC would fill more-completely but the machine is low on free RAM right now; Firefox is being a pig, and that means that some things get ejected from ARC before they can be sent to L2ARC.

It's generally quite responsive despite being a box that exclusively uses spinning rust as primary storage.

In terms of absolute reliability: RAIDZ2 is in-use, which allows two drives to fail without data loss. Adding the L2ARC did not change this: Either or both of L2ARC devices could die in an instant and the machine would keep moving along (at reduced performance).

(I'd planned to upgrade the hard drives to something bigger, which is a simple process with ZFS, and also add more RAM, but the market moved faster than I did and I'll be stuck with this for awhile.)

▲

Schlaefer an hour ago | parent | prev [-]

RAM cache is already layered in front of persistent storage. When it comes to easy hybrid SSD/HDD setups bcachefs was close to deliver, but then things jumped the shark.