Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi,
I am a new user to DRBD, and currently not getting very far with it,
primarily I believe because of the hardware platform I am running on.
This is an ARM (armel - little endian) platform, with only
128MB of RAM in total. I have tried this with top showing 30 megs free,
and 60 megs cached:
nasty:~# vmstat
procs -----------memory---------- ---swap-- -----io---- -system--
----cpu----
r b swpd free buff cache si so bi bo in cs us sy
id wa
0 0 1524 27248 4940 60736 12 13 141 95 68 75 4 2
94 0
I am running a custom 2.6.29 kernel, and have tried the drbd 8.3.1 and
8.3.2rc1 packages, built against my kernel. The userland tools are the
stock 8.3.1 debian tools from the debian armel build.
Currently, as I am testing I am using a 100M loopback image on both
systems, as the underlying storage. Perhaps this is the problem, but I
am loathed to re-partition my disks at this stage..
One system is i386 (no shortage of RAM here), which seems to behave
correctly. Both running same version of kernel and DRBD.
I don't think its getting as far as even attempting to communicate with
the other system, however I
mention it because, it works fine with the configuration I am using, on
the i386.
I have a very simple configuration:
global {
usage-count yes;
}
common {
protocol C;
}
resource r0 {
device /dev/drbd0;
disk /dev/loop0;
meta-disk internal;
on nasty {
address 192.168.0.1:7788;
}
on acid {
address 192.168.0.2:7788;
}
}
Loading the drbd driver seems fine:
-----------
kernel: drbd: initialised. Version: 8.3.1 (api:88/proto:86-89)
kernel: drbd: GIT-hash: fd40f4a8f9104941537d1afc8521e584a6d3003c build
by root at acid, 2009-06-09 23:39:13
kernel: drbd: registered as block device major 147
kernel: drbd: minor_table @ 0xc58dca20
----------
I am able to initialise the device metadata:
nasty:~# drbdadm create-md r0
Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.
success
However when I try to attach to the device:
nasty:~# drbdadm attach r0
No response from the DRBD driver! Is the module loaded?
Bad: fgets returned NULL while waiting for data: Interrupted system call
Looking in /var/log/kern.log
------------
kernel: drbd0: Unknown tag: 1071
kernel: Unable to handle kernel NULL pointer dereference at virtual
address 00000015
kernel: pgd = c1f14000
kernel: [00000015] *pgd=01530031, *pte=00000000, *ppte=00000000
kernel: Internal error: Oops: 1 [#1] PREEMPT
kernel: Modules linked in: drbd cn ipv6 nfsd exportfs ipt_MASQUERADE
iptable_nat nf_nat iptable_mangle xt_limit xt_tcpudp ipt_LOG
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack iptable_filter
ip_tables x_tables fuse asix usbnet mii
kernel: CPU: 0 Not tainted (2.6.29.4 #2)
kernel: PC is at fput+0x18/0x38
kernel: LR is at drbd_nl_disk_conf+0xb8/0x1284 [drbd]
kernel: pc : [<c00a6bcc>] lr : [<bf143900>] psr: 20000093
kernel: sp : c7b17ea0 ip : c7b17eb0 fp : c7b17eac
kernel: r10: c78e7000 r9 : 00000000 r8 : c7b3e400
kernel: r7 : c7a3ec24 r6 : c7a3ec10 r5 : 0000007e r4 : c7b3e458
kernel: r3 : c7b16000 r2 : 20000093 r1 : 20000013 r0 : 00000001
kernel: Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
kernel: Control: a005317f Table: 01f14000 DAC: 00000017
kernel: Process cqueue (pid: 3007, stack limit = 0xc7b16268)
kernel: Stack: (0xc7b17ea0 to 0xc7b18000)
kernel: 7ea0: c7b17f2c c7b17eb0 bf143900 c00a6bc4 c7b17ecc c7b17ec0
c00fd218 c00fd040
kernel: 7ec0: c7b17f04 c7b17ed0 c3cdc234 c00fd214 c01cb498 c01cba64
c7acb400 c00a1c30
kernel: 7ee0: c7b17f14 09300000 00000000 c7a3ec24 00000000 bf1587e0
c7b17f2c c7b17f08
kernel: 7f00: bf140e8c 00000003 c3cdc220 c7a3ec10 c7a3ec24 bf15888c
c78e7000 bf158874
kernel: 7f20: c7b17f5c c7b17f30 bf140ff4 bf143858 c7b17f54 c6dcf8c0
c7b16000 c5944d00
kernel: 7f40: c5944d00 bf110234 00000000 00000000 c7b17f74 c7b17f60
bf110254 bf140ed0
kernel: 7f60: a6431880 c6dcf8c8 c7b17f9c c7b17f78 c0057e94 bf110244
c5944d00 c5944d08
kernel: 7f80: c7b17fa4 c04a9418 00000000 00000000 c7b17fd4 c7b17fa0
c00586ac c0057dc0
kernel: 7fa0: 00000000 00000000 c662cf80 c005c9dc c7b17fb0 c7b17fb0
c04a9418 c7b16000
kernel: 7fc0: c5944d00 c0058650 c7b17ff4 c7b17fd8 c005c6f8 c0058660
00000000 00000000
kernel: 7fe0: 00000000 00000000 00000000 c7b17ff8 c00484bc c005c6b0
00000000 00000000
kernel: Backtrace:
kernel: [<c00a6bb4>] (fput+0x0/0x38) from [<bf143900>]
(drbd_nl_disk_conf+0xb8/0x1284 [drbd])
kernel: [<bf143848>] (drbd_nl_disk_conf+0x0/0x1284 [drbd]) from
[<bf140ff4>] (drbd_connector_callback+0x134/0x21c [drbd])
kernel: [<bf140ec0>] (drbd_connector_callback+0x0/0x21c [drbd]) from
[<bf110254>] (cn_queue_wrapper+0x20/0x40 [cn])
kernel: [<bf110234>] (cn_queue_wrapper+0x0/0x40 [cn]) from [<c0057e94>]
(run_workqueue+0xe4/0x1e8)
kernel: r4:c6dcf8c8
kernel: [<c0057db0>] (run_workqueue+0x0/0x1e8) from [<c00586ac>]
(worker_thread+0x5c/0xb8)
kernel: [<c0058650>] (worker_thread+0x0/0xb8) from [<c005c6f8>]
(kthread+0x58/0x94)
kernel: r6:c0058650 r5:c5944d00 r4:c7b16000
kernel: [<c005c6a0>] (kthread+0x0/0x94) from [<c00484bc>]
(do_exit+0x0/0x80c)
kernel: r7:00000000 r6:00000000 r5:00000000 r4:00000000
kernel: Code: e24cb004 e10f1000 e3812080 e121f002 (e5902014)
kernel: ---[ end trace 6cc142f573336846 ]---
-------------
Should DRBD work on this platform? Has anyone got it working? Am I doing
something obviously wrong?
Any help/suggestions appreciated
Regards
Nick