[DRBD-user] invalidate-remote does not work in StandAlone mode
mark-va3m46w7 at mstier.de
Fri Aug 5 11:44:53 CEST 2011
>> Can we fix that? I'm starting with a peerless configuration and the AL
>> updates are hurting performance without reason.
> In standalone, the AL isn't your only concern, there's also a quicksync
> bitmap that gets constantly updated (although that should be cheap).
> What are you trying to do? invalidate-remote doesn't make any sense
> while there's not peer you can invalidate. Even if there was, all you'd
> "gain" would be a mandatory full sync taking place on top of your AL woes.
I'm inserting the DRBD layer for on-demand VM migration purposes. Data
redundancy is by default done using local soft or hardware raid only, it
is not a failover or a network raid scenario. DRBD is only used to
minimize downtime while migrating the VM to another host which is not
I could possibly do that by using the dm layer to put the DRBD under the
VM when needed, but the disabled AL would be simpler and probably less
> Have you tweaked your al-extents setting?
Not good enough for some work loads.
> Have you tested whether operation with a peer is indeed slower?
That's not the reason.
> Have you compared Standalone DRBD performance with performance when not
> using DRBD at all?
well, I tested disabled AL against active AL. It's 100 random buffered
write ops against 40 per second. And yes, some work loads here are pretty
much like that. :-/
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119
More information about the drbd-user