>>> , >> >> 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 _______________________________________________ ceph-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
