DRBD and SSD: I was made for loving you

When DRBD 8.4.4 integrated TRIM/Discard support, a lot of things got much better… for example, 700MB/sec over a 1GBit/sec connection.

As described in the Root-on-DRBD tech guide, my notebook uses DRBD on top of an SSD; apart from the IO speed, the other important thing is the Trim/Discard support.

In practice that means, e.g., that the resync goes much faster: most of the blocks that were written while being off-site have already been discarded again, and so the automatical fstrim can drop the needed amount of data by “up to” 100%.

Result: with a single SSD on one end, 1GBit network connectivity, and thin LVM on top of a 2-harddisk RAID1 on the other end, a resync rate of 700MB/sec!

Here are the log lines, heavily shortened so that they’re readable; starting at 09:39:00:

block drbd9: drbd_sync_handshake:
block drbd9: self 7:4:4:4 bits:15377903 flags:0
block drbd9: peer 4:0:2:2 bits:15358173 flags:4
block drbd9: uuid_compare()=1 by rule 70
block drbd9: Becoming sync source due to disk states.
block drbd9: peer( Unknown -> Sec ) conn( WFRepPar -> WFBitMapS )
block drbd9: send bitmap stats total 122068; compression: 98.4%
block drbd9: receive bitmap stats: total 122068; compression: 98.4%
block drbd9: helper cmd: drbdadm before-resync-src minor9
block drbd9: helper cmd: drbdadm before-resync-src minor9 exit code 0
block drbd9: conn( WFBitMapS -> SyncSource ) 
block drbd9: Began resync as SyncSrc (will sync 58 GB [15382819 bits]).
block drbd9: updated sync UUID 7:4:4:4

At 09:40:27 the resync concludes; the first line is the relevant one:

block drbd9: Resync done (total 87 sec; paused 0 sec; 707256 K/sec)
block drbd9: updated UUIDs 7:0:4:4
block drbd9: conn( SyncSource -> Connected ) pdsk( Inc -> UpToDate ) 

That’s how it’s done 😉

2 replies
  1. Huiqun Zhou
    Huiqun Zhou says:

    It’s unbelievable that It reaches 700 MB/s on a 1 GbE connection. Hope you clarify what the “B” means, byte or bit? To me, even if it’s “bit”, it’s still fast enough.

    Reply
    • flip
      flip says:

      That’s the nice thing this post describes – the trim/discard requests needs only a few bytes on the wire, but bring A LOT of data into sync.

      Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *