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
signature.asc
Description: OpenPGP digital signature
