Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Wed, Feb 25, 2009 at 12:17:30PM +0100, GAUTIER Hervé wrote:
>
> Hi,
>
> Thank for your explanation about the usermode_helper.
> In order to not introduce any side effect, I will now install DRBD in
> the default way.
>
> Well, I have install again from scratch DRBD 8.3.0 _without_ PREFIX=...
> So now:
> - Sources are in /usr/local/drbd-8.3.0/source/drbd-8.3.0
> - Symbolic link /usr/local/drbd -> /usr/local/drbd-8.3.0
> - Build with "make all && make install".
> - Configuration file is /usr/local/drbd-8.3.0/etc/drbd.conf
> - DRBD module is now in /lib/modules/`uname -r`/kernel/drivers/block/drbd.ko
> - Userland tools are now in /sbin
>
> From my point of view, there is no more trace of previous
> installations, except the fact that my DRBD disks have been created with
> DRBD 8.2.5.
>
> All seems running well.
> Then I invalidate a resource, and while resynchronization time, I've got
> always the same problem.
> [root at rh4-2 libsh]# drbdadm -c ../etc/drbd.conf role drbd_res0
> Secondary/Secondary
> # (43) sync_progress = (integer) 833 [len: 4]
> [root at rh4-2 libsh]# type drbdadm
> drbdadm is hashed (/sbin/drbdadm)
> [pid 25405] execve("/sbin/drbdsetup", ["drbdsetup", "/dev/drbd0", "role"], [/* 32 vars */]) = 0
> Secondary/Secondary
> # (43) sync_progress = (integer) 878 [len: 4]
> And then no more strange message:
> -8<---------------------------------------------------------------------------
> # drbdadm -c ../etc/drbd.conf role drbd_res0
> Secondary/Secondary
> -8<---------------------------------------------------------------------------
>
> Help !
> I really don't understand what's happened.
>
> Any other idea than "using the older drbdadm/drbdsetup against the newer
> module" ???
ok.
first, this is NOT a problem.
it is just an "unexpected message".
no harm done.
believe me.
I know what generates that message.
This is only cosmetic.
if using the older userland against the newer module,
this had been expected (because the older userland does not expect the
sync_progress information in state answers).
I thought it would not appear, when using the correct userland against
the newer module. apparently, I'm wrong.
so I'll have a look why the "sync_progress" tag
is not consumed (and thus printf'ed explicitly...)
when using certain state functions during resync.
> BTW, I have seen a new file in ll /var/lib/drbd:
> -8<---------------------------------------------------------------------------
> [root at rh4-2 libsh]# ll /var/lib/drbd/
> total 16
> drwxr-xr-x 2 root root 4096 Feb 25 11:18 ./
> drwxr-xr-x 37 root root 4096 Feb 25 10:52 ../
> lrwxrwxrwx 1 root root 38 Feb 25 11:16 drbd-minor-0.conf -> /usr/local/drbd-8.3.0/etc/drbd.conf
> lrwxrwxrwx 1 root root 38 Feb 25 11:16 drbd-minor-1.conf -> /usr/local/drbd-8.3.0/etc/drbd.conf
> lrwxrwxrwx 1 root root 38 Feb 25 11:16 drbd-minor-2.conf -> /usr/local/drbd-8.3.0/etc/drbd.conf
> -rw------- 1 root root 36 Feb 25 11:18 node_id
> -8<---------------------------------------------------------------------------
>
> What is this node_id file ?
http://www.drbd.org/usage/introduction0/
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list -- I'm subscribed