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...
Even the corporate/enterprise multi-level HSMs has had to compete with rapid improvement in disk drive capacity.
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.
I was lucky to find you comment about how a lot can be done with tar mt and bash, I was doing something along the lines of trying to fit as much data as possible into a single tape without writing there more than it can be fit into one if possible, would you kind internet stranger happen to have a few wise words pointing me towards the solution or maybe a GitHub gist with an example of something along these lines? Thank you very much upfront!
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.
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.)
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.
It’s just easier done at the application layer. At a previous engagement, in the Before AI era, we originally had a block-level tiering solution that went from RAM to local nvme to NAS on striped flash to S3. It worked okay, but the application-level tiering worked better.
Would have loved a read-through union filesystem but you pretty much had to do your own.
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.
bcache is just the block level caching, with a different filesystem running on top of it. There's bcachefs. I'm using it on a computer exactly for this purpose.
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.
There is LVM Cache which uses dm-cache. That allows you to use SSDs to cache HDDs. Either can be RAIDed too. You can choose your file system because it happens at the block layer.
Besides the trivial caching on SSD there's also ways to do write buffering quite easily. I did that once a long time back when SSDs were too expensive for getting a 2TB disk. So probably ~10 years back.
That's exactly why I keep Windows on my NAS. You can configure storage tiering with arbitrary redundancy. You can have different redundancy on SSD and HDD tiers. As far as I am concerned ReFS gives me all the features of ZFS and doesn't eat my RAM. Also BitLocker + Secure Boot aren't pain in the ass there.
I will never buy electronics off of Amazon ever again. Whether they’ve fixed their mingling or not, they did it for years with no regrets. That level of contempt for customers deserves to be boycotted in perpetuity.
But you have to buy a pair, so the price is double.
You need a pair because if one HDD starts failing, you need to recover the data. Reading a 20 TB HDD takes an entire day of continuous reads, and a failing HDD can't handle that, so you need RAID 1 or a backup.
nice find! ServerPartDeals seems to be cheaper than Amazon tho. Sadly Amazon blocks agentic price watching but https://instinct.com/ has otherwise been great at watching HD prices.
There are existing price watch services for amazon (e.g. camelcamelcamel) that work very well... if you need agentic price watching in your workflow, just have your agent watch your email for price alerts.
If you have to provide your own SSD, I would think that the target audience already knows how to set up a cache disk in their NAS solution of choice, and they'd save a bunch of money that way.
I used to have one of their 2.5in hybrid drive in a laptop. Seemed to work well for games. But once SSD's became cheap the tech was not longer worth it. Also, 2.5in drives topped out at 2TB of storage, while NVME and 2.5 Sata SSD's continued to grow in size.
No? Plenty of 2.5" drives in 4TB size and bigger, for example the ST5000LM000 or a WD50NPZZ are 5TB ones. Unless you mean strictly newer laptops, that take 9.5mm or 7mm drives. Which are slim ones.
Yeah, wow. I hadn’t realised that the prices had gone up that much on hard disks as well. A pair of Synology 4TBs I bought for 2500SEK 18 months ago are now 3400SEK each from the same vendor.
I have 6x unused 6TB SAS drives I bought for $50 each in 2024. I assume they are $150 each now. I can't afford cold storage right now so I rely on raidz2 and can replace drives as they die.. But they have 2 years and no SMART errors.
Worse than that, sellers on Amazon all seem to be scams now[1], and my trusted local supplier (who has genuine parts) is only selling one hard disk per customer. Good luck populating a NAS.
"According to Seagate’s press release, the Alkemi intelligent storage platform takes a different approach. Where Apple’s Fusion Drives used tiering managed by macOS, Alkemi manages the storage pool directly from the enclosure."
Soooooo... it's gonna be like the old days of Drobo, where a little VXworks box did all the heavy lifting of BeyondRAID and transparently exposed it as a big ol' block device to your OS? Good times.
I’m not sure it’s realistic to expect an ordinary user to manage and tune tiered storage, so making it opaque to the OS, or even somewhat aware of the OS running on the computer via a device or filesystem driver, might be a sensible decision.
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.
- 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.
[1]https://github.com/openzfs/zfs/pull/16185
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.
The 8TB version seems like very poor value for money. For comparison, Amazon is selling 24 TB Seagate Exos drives for $799.
You need a pair because if one HDD starts failing, you need to recover the data. Reading a 20 TB HDD takes an entire day of continuous reads, and a failing HDD can't handle that, so you need RAID 1 or a backup.
Might be a scam, you might get a used or a refurb drive. I wouldn't' trust Amazon for such purchases, if the price feels too good.
Spoiled Americans. That drive is $1393 (14160 SEK) here in Sweden now[1]. A year ago it was 4160 SEK...
Three times as expensive in 12 months seems true for most drives.
I'm just praying no drives in my NAS are going to crap out anytime soon...
[1] https://www.prisjakt.nu/produkt.php?p=12519318
[1] example from when I was trying to buy NAS drives a few weeks back: https://www.amazon.co.uk/sp?marketplaceID=A1F83G8C2ARO7P&sel...
The dreaded communism came to the capitalistic states but not the way capitalists expected.
Soooooo... it's gonna be like the old days of Drobo, where a little VXworks box did all the heavy lifting of BeyondRAID and transparently exposed it as a big ol' block device to your OS? Good times.