Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Thu, Oct 25, 2012 at 04:09:02PM +0200, Felix Frank wrote: > Mostly what Adam said, but specifically: > > On 10/25/2012 03:38 PM, Whit Blauvelt wrote: > > In the case where that data was a normal > > filesystem, that's what DRBD does, right? That's the point of the offer to > > duplicate the existing data from primary to secondary? So with a normal > > filesystem, you can have a filesystem with data, add DRBD, and DRBD slips > > itself under the filesystem. > > DRBD doesn't slip itself under anything. It sets up a new block device > atop an existing block device. You can mount the filesystem contained in > this new block device. > > *Or* you scratch that and instead mount the same file system as seen in > the original block device. Thereby bypassing drbd and invalidating the > replicant instantly. Appreciate the clarification. Part of the problem is this isn't a simple 3-dimensional conceptual space. If you take a normal filesystem, add DRBD, and mount DRBD, or alternately if you take a DRBD mirror, add a filesystem and mount DRBD, you end up with the same result, right? So it doesn't matter which you picture as "on top" or "under" in that case. Metaphors can be inconsistent at different levels of abstraction. My shortcoming was not categorizing what libvirt-KVM-QEMU does as "mounting" when it's using a direct write to a raw partition. If my current, still sketchy understanding is right, did I only miss editing the XML file to change what's mounted by libvirt? I know about stupid mount tricks (I use GlusterFS in other contexts). Just wasn't linking that knowledge to this task. Sigh, Whit