- 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.
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.)
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.
Buying a Sony or IBM HSM with 20GB tapes backing a 5TB store (built with 2GB disks) soon looks pretty stupid when drives exceeded 40 and 80GB. (Adjust your calendar or drive scaling to match your expectations.)
Back in the day I worked on a quote for a European weather agency who wanted a CD-ROM archive built with robots. CD-ROM! DVD-R was just coming up in those days. The effective product lifespan would only have been 2 or 3 years until large scale enterprise disk would have superceded it.
Nowadays with multi-TB tapes the minimum viable archivable unit is in the gigabytes. Nobody would be 2million files on a single LTO tape.
HSM is really a product category: do you want write-only archive (think weather data, satellite images, etc). Are some files expirable so you want to actually eventually "delete" files by re-writing tapes with only valid data? What's the allowable time-to-first-byte on retrieval? What kind of redundancy is appropriate? What is the operating cost vs capital cost tradeoff? And, importantly, what database is supporting the metadata and how is it maintained?
Antipatterns:
- grep on a caching filesystem backed with a tape library - monthly retrievals of the same file year after year (even LTO has a limited tape operation lifetime) - management failure/refusal to migrate to newer tech every 4 years - buying 10 years of capacity in advance
You can get a lot done with tar, mt, and bash in a grow-your-own nearline archive with a tape technology of your choice.
Would have loved a read-through union filesystem but you pretty much had to do your own.
https://en.wikipedia.org/wiki/Bcache
https://en.wikipedia.org/wiki/Dm-cache
Sometimes I shoot over 100GB of raw photos and don't finish processing it all in 1 session. It would be nice if that got cached in an SSD rather than having to read the hard drive every time. But it's not a big enough issue for me test one of the caching layers.
RAM is always used first for caching, so it's a given.