Bug#623611: Lot of IO errors during boot

[Laurent Bigonville]

Le Thu, 23 Jun 2011 14:44:31 +0530,
Ritesh Raj Sarraf <rrs at debian.org> a écrit :

> On 06/23/2011 02:31 PM, Laurent Bigonville wrote:
> > It's just to add a comment (tell me if it worth reopening the bug).
> >
> 
> There's not much to do here. So let's leave it closed.

OK

> 
> > I've discovered that the more LUN mapped to a machine you have, the
> > more time the machine takes to boot (due to the IO errors) and well
> > in some situations it's not acceptable.
> > 
> 
> That's ought to happen given the design. Ideally, there should be a
> mechanism to ignore the ghost devices. Have you discussed this on
> dm-devel?
 
Well multipath is not even running at that time, so without any help
(scsi_dh_rdac) the kernel know nothing about the sdX device.

I should probably talk about that on the ml. I've other weirdness with
the target I'm using but I'm a bit ENOTIME at the moment.

> BTW, how many devices (LUNs x Paths) are we talking here ?

Well I was testing with 5 lun (2 active paths and 2 inactives).

> 
> > I've found on a centos ML[0] that loading the scsi_dh_rdac kernel
> > module really early (in the initrd) could mitigate this issue. I've
> > made some test and it seems to work if the module is loaded in
> > init-top (and before udev). I'm not too sure this is possible to
> > do, as it seems that the 1st script to load (scsi) modules is the
> > udev one.
> >
> 
> The only reason to put something into initrd is for early boot. In
> case of storage, if your root LUN is on a SAN. Otherwise, I don't see
> a need. But if you feel that putting it into initrd is helping, go
> with it. Does the rdac module have any initialization delay ?

Looks like that even with multipath-utils-boot package installed, this
module is not loaded either before udev is started.

initialization delay? Not too sure what you mean, the module seems
to load instantaneously.

Cheers

Laurent Bigonville