Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Just a bit more info ... found this in my dmesg:
kobject_add failed for drbd102 with -EEXIST, don't try to register things
with the same name in the same directory.
Call Trace:
[<ffffffff802e6727>] kobject_add+0x174/0x19f
[<ffffffff802dde50>] exact_lock+0x0/0x14
[<ffffffff80340b22>] cn_queue_wrapper+0x0/0x23
[<ffffffff802b9406>] register_disk+0x43/0x199
[<ffffffff80340b22>] cn_queue_wrapper+0x0/0x23
[<ffffffff802ddfd9>] add_disk+0x34/0x3d
[<ffffffff882605c6>] :drbd:drbd_new_device+0xd5/0x1fc
[<ffffffff8826297d>] :drbd:ensure_mdev+0x3b/0xde
[<ffffffff88265676>] :drbd:drbd_connector_callback+0x41/0x1d9
[<ffffffff80340b22>] cn_queue_wrapper+0x0/0x23
[<ffffffff80340b2d>] cn_queue_wrapper+0xb/0x23
[<ffffffff8023e53b>] run_workqueue+0x94/0xfe
[<ffffffff80241a4d>] keventd_create_kthread+0x0/0x61
[<ffffffff8023f0c3>] worker_thread+0x104/0x13d
[<ffffffff80227086>] default_wake_function+0x0/0xe
[<ffffffff8023efbf>] worker_thread+0x0/0x13d
[<ffffffff80241cc3>] kthread+0xd4/0x109
[<ffffffff8020afb8>] child_rip+0xa/0x12
[<ffffffff80241a4d>] keventd_create_kthread+0x0/0x61
[<ffffffff80241bef>] kthread+0x0/0x109
[<ffffffff8020afae>] child_rip+0x0/0x12
On Mon, Feb 2, 2009 at 12:00 AM, Sam Howard
<sam.howard at officepcsupport.com>wrote:
> Hi.
> I'm still struggling to get a stacked device to work on DRBD 8.3.0.
>
> Config excerpt:
>
> common {
> syncer {
> rate 70M;
> verify-alg md5;
> }
>
> protocol C;
>
> startup {
> wfc-timeout 0; ## Infinite!
> degr-wfc-timeout 120; ## 2 minutes.
> }
>
> disk {
> on-io-error detach;
> }
>
> net {
> allow-two-primaries;
> }
> }
>
> resource ftp01-root {
> device /dev/drbd2;
> disk /dev/datavg/ftp01-root;
> flexible-meta-disk internal;
>
> on xen-33-18-02 {
> address 192.168.250.12:7702;
> }
>
> on xen-33-18-03 {
> address 192.168.250.13:7702;
> }
> } # ftp01-root
>
> resource ftp01-root-b {
> device /dev/drbd2;
> disk /dev/datavg/ftp01-root;
> meta-disk /dev/datavg/drbd_log[2];
>
> on xen-80-31-00 {
> address 192.168.250.14:7702;
> }
>
> on xen-80-31-01 {
> address 192.168.250.15:7702;
> }
> } # ftp01-root-b
>
> resource ftp01-root-r {
> protocol A;
>
> stacked-on-top-of ftp01-root {
> device /dev/drbd102;
> address 10.80.31.51:7702;
> }
>
> stacked-on-top-of ftp01-root-b {
> device /dev/drbd102;
> address 10.80.31.50:7702;
> }
> } # ftp01-root-r
>
> =========================================
>
> I have the ftp01-root device up and running (currently in use and working
> fine). I build my new server (xen-80-31-00) and got its device
> "ftp01-root-b" running.
>
> xen-33-18-03 (ftp01-root):
> 2: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r---
> ns:2176532 nr:999236 dw:3190465 dr:2068626 al:79 bm:78 lo:0 pe:0 ua:0
> ap:0 e
> p:1 wo:b oos:1420
>
> xen-80-31-00 (ftp01-root-b):
> 2: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r---
> ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:4194304
>
> On both hosts, the other node is down, hence the "DUnknown" for the second
> host.
>
> Trying to create the stacked device fails with:
>
> root at xen-33-18-03:/etc# drbdadm --stacked up ftp01-root-r
> /dev/drbd102: Failure: (127) Device minor not allocated
> Command 'drbdsetup /dev/drbd102 disk /dev/drbd2 /dev/drbd2 internal
> --set-defaults --create-device --on-io-error=detach' terminated with exit
> code 10
>
> I do see the device (/dev/drbd102) *is* getting created:
>
> brw-rw---- 1 root disk 147, 102 2009-02-02 01:37 /dev/drbd102
>
> Google has not been much help, and I'm really stuck now.
>
> Just to make it more fun, it seems the batch of Samsung 750GB drives that
> are in the xen-33-18-xx servers aren't very good and I'm loosing drives left
> and right, so I need to get this data moved ASAP.
>
> What can I try next?
>
> Thanks,
> Sam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20090202/7bf12d6d/attachment.htm>