Le Thu, 23 Jun 2011 14:44:31 +0530, Ritesh Raj Sarraf <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
