Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2005-07-28 09:12:49 +1000 \ Bradley Baetz: > I'm trying to test the 0.7.11 version of drbd (upgrading from 0.6 on a > 2.4 kernel). > > In order to test the new detach functionality, I did |drbdadm detach drbd0|. > This seemed to work, with the system going into DiskLessClient state, > and postgresql continuing to work as expected. > > [root at dbtools01.syd ~]# cat /proc/drbd > version: 0.7.11 (api:77/proto:74) > SVN Revision: 1807 build by root at build03.syd.optusnet.com.au, 2005-07-27 16:07:12 > 0: cs:DiskLessClient st:Primary/Secondary ld:Consistent > ns:10119312 nr:1052948 dw:11172260 dr:551285 al:128 bm:516 lo:0 pe:0 ua:0 ap:0 > > I then wanted to reattach drbd to its drive. A reattach failed, since > the device was still primary (drbd_ioctl_set_disk: (mdev->state != Se > condary)). I then did a takeover onto the other node, and that produced: > > Jul 28 08:45:08 dbtools01 kernel: drbd0: Primary/Secondary --> Secondary/Secondary > Jul 28 08:45:08 dbtools01 kernel: drbd0: drbd_md_write: (!inc_local_md_only(mdev)) in /usr/src/redhat/BUILD/drbd-0.7.11/drbd/drbd_main.c:1991 > Jul 28 08:45:09 dbtools01 kernel: drbd0: mdev->backing_bdev==NULL > Jul 28 08:45:09 dbtools01 kernel: [<f8a45e78>] drbd_determin_dev_size+0x160/0x2e7 [drbd] > Jul 28 08:45:09 dbtools01 kernel: [<f8a4d38a>] drbd_recv+0x8f/0x23c [drbd] > Jul 28 08:45:09 dbtools01 kernel: [<f8a50cc0>] receive_param+0x552/0xa23 [drbd] > Jul 28 08:45:09 dbtools01 kernel: [<f8a5076e>] receive_param+0x0/0xa23 [drbd] > Jul 28 08:45:09 dbtools01 kernel: [<f8a518fe>] drbdd+0xbd/0x10d [drbd] > Jul 28 08:45:09 dbtools01 kernel: [<f8a525ac>] drbdd_init+0xde/0x2d0 [drbd] > Jul 28 08:45:09 dbtools01 kernel: [<f8a58c19>] drbd_thread_setup+0x81/0x147 [drbd] > Jul 28 08:45:09 dbtools01 kernel: [<f8a58b98>] drbd_thread_setup+0x0/0x147 [drbd] > Jul 28 08:45:09 dbtools01 kernel: [<c01041d9>] kernel_thread_helper+0x5/0xb this looks similar to an oops, but in fact it is only a debug stack dump, explicitly triggered by us if we try to access the backing device, but then figure we don't have any. Maybe we should not trigger this if we know and expect that we don't have one :-) > Jul 28 08:45:09 dbtools01 kernel: drbd0: Secondary/Secondary --> Secondary/Primary > Jul 28 08:45:09 dbtools01 kernel: drbd0: drbd_md_write: (!inc_local_md_only(mdev)) in /usr/src/redhat/BUILD/drbd-0.7.11/drbd/drbd_main.c:1991 > > But it still seemed fine: > > [root at dbtools01.syd ~]# cat /proc/drbd > version: 0.7.11 (api:77/proto:74) > SVN Revision: 1807 build by root at build03.syd.optusnet.com.au, 2005-07-27 16:07:12 > 0: cs:DiskLessClient st:Secondary/Primary ld:Consistent > ns:10119692 nr:1052948 dw:11172260 dr:551285 al:128 bm:516 lo:0 pe:0 ua:0 ap:0 > > Then on giveback, the system started doing a full sync: > Is this expected behaviour? yes. > I would have expected that the quick resync would have taken place. if you "detach" (explicitly, or due to io-error on the backing device), we have to expect that you _change_ the backing device (you literally go there, take out the bad drive, and plug in a new one). thus, we expect that new drive to not contain any related data, so we need a full sync. -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schoenbrunner Str. 244, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client.