Re: init scripts problems ?

"Also sprach denis bonnenfant:"
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> Peter T. Breuer wrote:
> > "Also sprach denis bonnenfant:"
> > As I said - back out the tasklet patch.
> > 
> 
> Done.
> 
> It works pretty well, except
> there is still the problem with raid :

I'll have to investigate that in the coming days. Anything you can do
to get the problem down to a minimal configuration would be useful -
plus all the data available about the problem state, of course.
> 
> when stopping client member of an array, it's ok : nda is faulted
> 
> ldap:~# cat /proc/mdstat
> Personalities : [raid1]
> md0 : active raid1 nda[2](F) sda[0]
>        104768 blocks [2/1] [U_]
> 
> unused devices: <none>
> 
> starting client has a strange effect  :
> nda is removed  from the array !

Well, one would want to know if the HOT_ADD ioctl is sent from nbd.
Grep in the enbd source ofr HOT_ADD and add some printks nearby if there
aren't any.

> ldap:~# cat /proc/mdstat
> Personalities : [raid1]
> md0 : active raid1 sda[0]
>        104768 blocks [2/1] [U_]

Curious. I wuld have to look in the md code to see why. It's the
md_seq_show() code in md.c

   if (mddev->pers || mddev->raid_disks || !list_empty(&mddev->disks)) {
                   seq_printf(seq, "%s : %sactive", mdname(mddev), mddev->pers ? "" : "in");


Then there's a

    ITERATE_RDEV(mddev,rdev,tmp2) {
                           char b[BDEVNAME_SIZE];
                           seq_printf(seq, " %s[%d]", ...


And there's NO WAY of skipping printing something in my code. Therefore
the kernel is kaput. My code alwas has at least

    seq_printf(seq, " %s[%d]",
        bdevname(rdev->bdev,b), rdev->desc_nr); 
    if (rdev->faulty) {
             seq_printf(seq, "(F)");
             continue;
    }

so it can't skip. Care to look at yours?



> I'm not pretty sure, but it looks like md is notified that client is restarted and is trying to
> read sb on nda before the link is really active  :

It's possible - that kind of thing can be checked. The notification is
sent, however, when the device has just been enabled, so it will at
worst _block_ (i.e. it won't reject) requests until it is really ready.

> Dec  7 17:18:02 ldap enbd-client: enbd-client: client (1) set sig uses whole disk, wants slot 2
> Dec  7 17:18:02 ldap enbd-client: enbd-client: client (1) set sig or passed sigchk OK
> Dec  7 17:18:02 ldap enbd-client: enbd-client: client (1) sig matched OK
> Dec  7 17:18:02 ldap enbd-client: enbd-client: client (1) begins main loop
> 
> So the md is still connected to a dead nbd client, and the new one is not able to talk with md, resulting to this mismatch, as the dead client is 
> still referenced by md array, with pending requests preventing from stopping the array.

But of course md is not "connected" to a client, but a device.  That
device (nbd) is serviced by a client - the md device doesn't know
anything about clients and doesn't talk to them.

If there is a problem, it is that the old client hasn't died.

> Is there a way to get more info about md device, to know exactly why it is stuck ?

Well, adding a few printks! Lots of experiments too. But first find out
how come it can not show the device in the printout. That looks
impossible to me! 

After the impossible has happened, anything is possible, so try and
eliminate it ...

Peter