Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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].