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 _______________________________________________ drbd-user mailing list [email protected] http://lists.linbit.com/mailman/listinfo/drbd-user
