Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
I notice I've hit a nerve ;-) DRBD is a great product, and I realize it's not a panacea and shouldn't be used in braindead ways. I'm just trying to understand how it works, and have come across some surprised (e.g. the in-memory thing, normally when a write is 'in-memory', the host will also assume that's what's on disk and service a read from there, not apparently the case with active-active DRBD). If you've got a target that will run in passthrough mode (where it does nothing but relay scsi commands to the drbd device), for infiniband or fibrechannel, and only one client reading/writing, is there still an issue in protocol C? Everything is relying on the one client to keep consistency. I'm only familiar with the basic function of DRBD, but without it, in a classic multipath scenario you're treating everything as separate block devices, even though they're the same. Independent target processes that don't share information, exporting what look to be separate block devices but same backing store, and the client is able to write to them independently and expect consistency only because it is in control of what goes there, just like OCFS2 is in control on top of active-active DRBD. I realize this has apparently been a hot button issue, and I apologize if I sound argumentative, I just want to understand myself. I would have expected reads to be consistent on both DRBD nodes, and writes to be so as well (at least in protocol C), so the fact that adding DRBD suddenly requires my various target threads to talk to each other and be cluster aware, even though they were already independently acting on the same storage is something I want to understand. Thanks for the links and info.