[DRBD-user] invalidate-remote does not work in StandAlone mode

[Mark]

Hello Felix!

>> 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
known beforehand.

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
error-prone.

> 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. :-/

Best regards,
Mark


-- 
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
[http://www.ietf.org/rfc/rfc2119.txt].