[DRBD-user] drbd on ramdisks

Lars Ellenberg lars.ellenberg at linbit.com
Thu Dec 9 17:03:11 CET 2010

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


On Wed, Dec 08, 2010 at 11:29:42AM -0200, Andre Nathan wrote:
> On Tue, 2010-12-07 at 14:47 -0200, Andre Nathan wrote:
> > It seems the problem only occurs when you have resources on physical
> > volumes and on ram disks simultaneously. I can create these resources as
> > usual, but after a reboot the resource on the ramdisk stops working (as
> > expected, I guess, because the metadata was lost on the reboot) but then
> > drbdadm create-md results in the error I mentioned.
> 
> I tried working around this by using tmpfs. I created a large file in a
> tmpfs volume, and used losetup to map the file to a device. Then I
> created a DRBD volume on /dev/loop0.
> 
> I can bring up the resource fine, but it breaks during synchronization:
> 

> Dec  8 10:26:58 wcluster1 kernel: [ 1699.000927] block drbd2: Handshakesuccessful: Agreed network protocol version 94
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.000944] block drbd2:conn( WFConnection -> WFReportParams ) 
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.000976] block drbd2: Startingasender thread (from drbd2_receiver [2161])
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.001098] block drbd2:data-integrity-alg: <not-used>
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.001191] block drbd2:drbd_sync_handshake:
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.001198] block drbd2: selfD608531CD3061EE3:0000000000000004:0000000000000000:0000000000000000bits:262127 flags:0
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.001204] block drbd2: peer0000000000000004:0000000000000000:0000000000000000:0000000000000000bits:262127 flags:4
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.001209] block drbd2:uuid_compare()=2 by rule 30
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.001212] block drbd2: Becomingsync source due to disk states.
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.001216] block drbd2: Writingthe whole bitmap, full sync required after drbd_sync_handshake.
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.001380] block drbd2: 1024 MB(262127 bits) marked out-of-sync by on disk bit-map.
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.001427] block drbd2:peer( Unknown -> Secondary ) conn( WFReportParams -> WFBitMapS )pdsk( Outdated -> Inconsistent ) 
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.241078] block drbd2:conn( WFBitMapS -> SyncSource ) 
> Dec  8 10:26:58 wcluster1 kernel: [ 1699.241098] block drbd2: Beganresync as SyncSource (will sync 1048508 KB [262127 bits set]).
> Dec  8 10:27:19 wcluster1 kernel: [ 1719.729138] block drbd2: read:error=-28 s=523520s
> Dec  8 10:27:19 wcluster1 kernel: [ 1719.729148] block drbd2: Resyncaborted.
> Dec  8 10:27:19 wcluster1 kernel: [ 1719.729156] block drbd2:conn( SyncSource -> Connected ) disk( UpToDate -> Failed ) 
> Dec  8 10:27:19 wcluster1 kernel: [ 1719.729165] block drbd2: Local IOfailed in drbd_endio_read_sec_final.Detaching...
> Dec  8 10:27:19 wcluster1 kernel: [ 1719.729223] block drbd2: read:error=-28 s=523584s
> Dec  8 10:27:19 wcluster1 kernel: [ 1719.729235] block drbd2: read:error=-28 s=523648s

ENOSPC on read is a tad unusual.
I think your experiment is just broken,
and that's certainly not DRBD's fault.
Maybe you overcomitted too much?

> Dec  8 10:27:21 wcluster1 kernel: [ 1721.887452] block drbd2: in
> got_BlockAck:4348: rs_pending_cnt = -1 < 0 !
> 
> This last message is repeated many times with varying rs_pending_cnt.

Retry with latest DRBD,
that one should be fixed.

and always state the version you are using when asking for advice
on "strange behaviour" ;-)

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list   --   I'm subscribed



More information about the drbd-user mailing list