Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
I'd expect that if he's seeing sync's running faster than application
level writes, then there is an issue with write-barriers. DRBD is taking
steps to provide write-ordering protection, which aren't relevent to
bulk/block copying of re-syncing.
e.g. http://www.drbd.org/users-guide/re-drbdconf.html
no-disk-barrier , no-disk-flushes , no-disk-drain
but I'm no expert either.
-Tom
On Fri, 1 May 2009, Andrew (Anything) wrote:
> Im by no means an expert at this.
>
> But im pretty sure that If your network is only able to do 120MB/sec that
> would be the best youll get.
>
> protocol C wont finish each write until it is sent over the network and
> confirmed by the other side.
>
>
>
> While syncing its probably faster because it just adds the writes to be done
> on the end of the al-extents queue?
>
>
>
> How are your nodes connected?
>
>
>
> Andy..
>
>
>
> I'm getting an odd speed gap between the top speed of a full resync, and the
> speed of actual writing to the primary connected node. On a full resync
> (after invalidate), I'm getting about 400MB/s, however doing plain
> sequential writes to the primary connected node (when fully synced of
> course) only gives about 120MB/s. If I disconnect the node, the write speeds
> are doubled. Both nodes are identical in this behavior, so there's no case
> of one being slower than the other.
>
> There's no notable difference in this behavior when changing the protocols
> (even to A), al-extents or max-buffers. Is there anything else that I might
> be missing?
>
> Thanks,
>
> -Gennadiy