Le 10/04/2026 10:23 CEST, Janne Johansson <icepic.dz@gmail.com> a écrit :
A second cache mode is "writeback". Writeback delays writing data blocks from the cache back to the origin LV. This mode will increase performance, but the loss of a cache device can result in lost data.
So, so much for that. Writethrough will not help my situation, and writeback can cause data loss. This leads to two questions:
This isn't much different from OSD on one slow drive and WAL+DB on fast(er) drive.
If wal+db disk dies, the OSD is for all practical purposes "dead" too. It is one of the things at least we accept when we use 4-6 WAL+DB-partitions on a single nvme for our spindrive hosts. Most of those have 12 drives so 2 or 3 nvmes are in there and yes losing an nvme would be bad, but still less bad than losing the host, which could occur at any time for some kernel crash or PSU fault, so losing an nvme for us, is like losing half a host, and our clusters need to be able to withstand losing a whole host so for us, it's a decent enough tradeoff.
On that we agree: WAL+DB dead is a dead OSD. And it's indeed a fair tradeoff: I'd expect the bad backend drives to die long before the enterprise write-intensive drives I have for wal+db. (or, in the case of spinning rust, I'd expect a mechanical failure long before a flash failure).
Regardless of how you set up "ssd" acceleration in front of slower disks, there will be a window where if the ssd breaks, bad things happen to the slow disk OSD behind it. Yes, write-back makes that window larger, but you probably won't get a zero timespan for catastrophes in any case.
So if the cache lives on the same physical drive as the WAL+DB (fast SSD), it basically nullifies the "writes to block without cache" scenario as block.db would also be missing. The timespan won't be zero, but the OSD is essentially dead, so the corrupted data does not matter. Thus, in the end, it's no different from a dedicated wal+db iff wal+db stays dedicated: I've seen people suggest to keep wal+db colocated if there's a fast flash in front of the drive, as wal+db would essentially always be hot in the cache. As a summary: the following is safe data-wise: fast drive drops -> block.db drops -> dirty writeback data in cache does not matter. ┌──────────────┐ ┌────────────┐ │ Crap drive 1 │ │ Fast drive │ ├──────────────┤ ├────────────┤ ├──────────────┤ ├────────────┤ ┌───────┐ │ block ├──┐ │ block.db ├──┬──────────┤ osd.x │ └──────────────┘ │ ├────────────┤ │ └───────┘ │ │ block.db ├──┼─┐ ┌──────────────┐ │ ├────────────┤ │ │ ┌───────┐ │ Crap drive 2 │ └─┤ cache ├──┘ ├────────┤ osd.y │ ├──────────────┤ ├────────────┤ │ └───────┘ ├──────────────┤ ┌─┤ cache ├────┘ │ block ├──┘ └────────────┘ └──────────────┘ (note: I know that the OSD thinks it directly talks to the crap drives, but it's simpler to diagram it this way) Thanks! Alexis
-- May the most significant bit of your life be positive.