Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
If you use DRBD on ARM (armel), I would very much appreciate knowing how well
drbdsetup 0 show
works on your systems.
On my system (two Dreamplugs running Debian squeeze with a 3.0.0 kernel and
drbd8-utils 8.3.11), I get the following failure to interpret device addresses:
disk {
size 0s _is_default; # bytes
on-io-error detach;
fencing dont-care _is_default;
max-bio-bvecs 0 _is_default;
}
net {
timeout 60 _is_default; # 1/10 seconds
max-epoch-size 2048 _is_default;
max-buffers 2048 _is_default;
unplug-watermark 128 _is_default;
connect-int 10 _is_default; # seconds
ping-int 10 _is_default; # seconds
sndbuf-size 0 _is_default; # bytes
rcvbuf-size 0 _is_default; # bytes
ko-count 0 _is_default;
allow-two-primaries;
after-sb-0pri disconnect _is_default;
after-sb-1pri disconnect _is_default;
after-sb-2pri disconnect _is_default;
rr-conflict disconnect _is_default;
ping-timeout 5 _is_default; # 1/10 seconds
on-congestion block _is_default;
congestion-fill 0s _is_default; # byte
congestion-extents 127 _is_default;
}
syncer {
rate 20480k; # bytes/second
after -1 _is_default;
al-extents 257;
verify-alg "crc32c";
on-no-data-accessible io-error _is_default;
c-plan-ahead 0 _is_default; # 1/10 seconds
c-delay-target 10 _is_default; # 1/10 seconds
c-fill-target 0s _is_default; # bytes
c-max-rate 102400k _is_default; # bytes/second
c-min-rate 4096k _is_default; # bytes/second
}
protocol C;
_this_host {
device minor 0;
disk "/dev/sda1";
meta-disk internal;
address [unknown af=512, len=16]
}
_remote_host {
address [unknown af=512, len=16]
}
The address family number "512" is very suspicious to me. If represented as an
unsigned short, it is "0x0200" which is just a byte-swap away from "0x0002" which
is the correct value of AF_INET (ipv4).
This is not the first time that DRBD on armel has had difficulties. There is a
long thread (http://lists.linbit.com/pipermail/drbd-user/2009-June/012231.html)
of a bug with similar symptoms caused by broken gcc optimisation.
Indeed, when I enable misaligned access warnings with
echo 1 > /proc/cpu/alignment
dmesg shows
[1025904.322890] Alignment trap: drbdsetup (12842) PC=0x0000c488 Instr=0xe1d050b0 Address=0xbeeeb521 FSR 0x001
[1025904.334094] Alignment trap: drbdsetup (12842) PC=0x0000c4b0 Instr=0xe1d410b0 Address=0xbeeeb521 FSR 0x001
[1025904.346980] Alignment trap: drbdsetup (12842) PC=0x0000c488 Instr=0xe1d050b0 Address=0xbeeeb535 FSR 0x001
[1025904.357365] Alignment trap: drbdsetup (12842) PC=0x0000c4b0 Instr=0xe1d410b0 Address=0xbeeeb535 FSR 0x001
[1025904.369748] Alignment trap: drbdsetup (12842) PC=0x0000dac0 Instr=0xe194a0b5 Address=0xbeeeb501 FSR 0x001
If you have suggestions on how to fix this or simply can confirm that DRBD
works (or not) on your armel systems, I would greatly appreciate your input.
Thanks.
--
Erik Rossen
rossen at rossen.ch
http://www.rtfm-sarl.ch
OpenPGP key: 2935D0B9