Bug#623611: Lot of IO errors during boot

[Laurent Bigonville]

Le Thu, 23 Jun 2011 15:52:06 +0530,
Ritesh Raj Sarraf <rrs at debian.org> a écrit :

> On 06/23/2011 03:12 PM, Laurent Bigonville wrote:
> > Le Thu, 23 Jun 2011 14:44:31 +0530,
> >>> 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.
> >
> 
> So is this being concluded as a scsi rdac issue?

Problably

> >> 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.
> >
> 
> The prio libs are part of the initrd the moment initramfs seen
> dm-multipath enabled. As for the scsi module, I think the MODULES=most
> option should take care of it.

Well the module is in the initrd, but it seems that nothing is loading
it before udev is started. So maybe we should request udev to load the
modules at some point.

> 
> 
> > initialization delay? Not too sure what you mean, the module seems
> > to load instantaneously.
> > 
> 
> From what you've mentioned on the top, it looks like the [scsi]device
> discovery is slow. But this is just my guess. I've never worked with
> that hardware.

Well not that much. It's all the udev discovery on inactive devices
that is slowing down things.

Cheers

Laurent Bigonville