Bug#623611: Lot of IO errors during boot

[Ritesh Raj Sarraf]

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?

> 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.
> 

Yes, I think that'll clear up things.

>> BTW, how many devices (LUNs x Paths) are we talking here ?
> 
> Well I was testing with 5 lun (2 active paths and 2 inactives).
>

That's a very low number.

>> 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.


> 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.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20110623/3e2438c4/attachment-0001.pgp>