Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tue, Apr 01, 2008 at 03:43:32PM -0400, Pollock, Dan wrote:
> Thank-you for the info.
>
> Just so you know, I wrote some scripts to install and re-install drbd
> over and over all weekend and found that the disconnect was the only
> reason that I ever got into an unusable state except 5 or 6 other
> reasons. A few stuck on WFBitmaps and twice "read_in_block: (data_size
> & 0x1ff) in /usr/src/drbd-8.2.5/drbd/drbd_receiver.c:948" which I'm
> still trying to reproduce.
>
> I am currently using 8.2.5, should I use the 8.0 line instead? (I am
> not using dual primary, and only replicating 3M of data on an 8M
> partition).
8.2 is fine,
it receives any bugfixes done in the 8.0 series,
plus new features. the later may scare the more conservative,
which is why 8.0 will still be around for quite a while.
> Also, are there ways of enabling extra debugging output? I am going to
> be continuing these tests for the next few weeks so I'd like to get more
> output if those one in a million situations occur.
um, yes. we should write some "which is what" guide.
the knobs are in /sys/module/drbd/parameters/, namely
trace_devs: bitfield of which minor the tracing is enabled on
trace_level: increasing this gives more detail (0 to 4, iirc)
trace_type: bitfield of which kind of debugging you are interested in
TraceTypePacket = 0x00000001,
TraceTypeRq = 0x00000002,
TraceTypeUuid = 0x00000004,
TraceTypeResync = 0x00000008,
TraceTypeEE = 0x00000010,
TraceTypeUnplug = 0x00000020,
TraceTypeNl = 0x00000040,
TraceTypeALExts = 0x00000080,
TraceTypeIntRq = 0x00000100,
(bitor them together)
be aware that this will flood your kernel logs,
and may seriously slow down the box if you have
a serial console configured and the console log level is set too high.
if you enable all of that,
it is probably much more detail than you ever wanted to know.
then there is the command
drbdsetup /dev/drbd0 events -u -a
iff drbd gets "stuck", though, most helpfull are just the last events
as recorded in the kernel log, and what the respective drbd kernel
threads are doing right now.
ps -eo pid,state,wchan:30,cmd | grep -e D -e drbd
and maybe
echo w > /proc/sysrq-trigger
or even
echo t > /proc/sysrq-trigger
--
: Lars Ellenberg http://www.linbit.com :
: DRBD/HA support and consulting sales at linbit.com :
: LINBIT Information Technologies GmbH Tel +43-1-8178292-0 :
: Vivenotgasse 48, A-1120 Vienna/Europe Fax +43-1-8178292-82 :
__
please use the "List-Reply" function of your email client.