,
Reads are always served from the slow device, and writes over a certain size go there directly.
My understanding from dm-cache docs was that no, in plain dm-cache, reads hit the cache drive. For the behavior you describe (only writes use the cache), you'd need dm-writecache, which is another mode for dm-cache.
Clarify: I was talking about conventional offloaded WAL+DB, not dm-cache.
As for the write size, I guess it's configurable, but I don't think it'll be an issue for my case: what I'm after is preventing the constant chatter or small random writes that hit the drive with a sustained workload. The occasional big write should not matter too much.
That’s what I was after. One potential strategy is fronting coarse-IU QLC SSDs, in which case one would reeeealy want the writes to the backing device to be an aligned, even multiple of the IU.
I've seen use-cases where the hassle of WAL+DB offload doesn't actually make an appreciable improvement.
I guess it really depends on the drive you have. For HDDs it's a no brainer as far as I understand it,
I’ve worked with an HDD cluster that added colocated HDDs to existed offloaded HDDs. 40% of the OSDs were colocated and nobody noticed. There are no doubt workloads where it would make a bigger difference.
but for SSDs you'd hit diminishing returns, even with NVMe WAL+DB.
Absolutely. And new spend on SAS / SATA SSDs these days is a bad idea. They are disappearing from the market.
It's a case where transparent caching of block with an NVMe would make an improvement where WAL+DB does not Yep
Alexis