|
I actually tried doing that by
doing a mkinitrd /boot/initrdfile –preload=scsi_dh_rdac kernelversion and
booted using the initrd and it still seemed to crank out quite a few
errors. With doing it this way, should I still expect to see a good deal
of I/O errors or should they pretty sparse? From:
dm-devel-bounces@xxxxxxxxxx [mailto:dm-devel-bounces@xxxxxxxxxx] On Behalf
Of Moger, Babu Yes, this could happen during the boot where the scsi_dh_rdac handler is not yet loaded. You might want to try adding
scsi_dh_rdac in the initrd. This will help to cut short all your error
messages. I don’t see any problem with your multipath.conf. Thanks Babu Moger From:
dm-devel-bounces@xxxxxxxxxx [mailto:dm-devel-bounces@xxxxxxxxxx] On Behalf
Of Kurt Bechstein Greetings everyone, I have a RHEL 5.3 host attached to two
Dell MD3000i storage arrays via iscsi. I’m having some interesting
issues upon bootup in this setup. Between the two arrays I’m
accessing 24 luns so after my iscsi service kicks in I get tons and tons of I/O
error messages going across the screen. This can go on for 15-20 minutes
or longer. It would appear that some I/O is being sent to the passive
paths and they are returning errors. It would seem the scsi layer is
doing its thing to scan for partitions and probably causing the I/O that is
being seen. Is there any way to suppress/avoid this scenario? Also,
I thought I would post my multipath.conf file just to have some other eyes have
a look at it and make sure I’m not missing something obvious so that is
below. Thanks in advance! devices { device {
vendor
"DELL"
product
"MD3000i"
features
"0"
getuid_callout
"/sbin/scsi_id -g -u -s /block/%n"
prio_callout
"/sbin/mpath_prio_rdac /dev/%n"
hardware_handler "1 rdac"
path_grouping_policy group_by_prio
failback
immediate
path_checker
rdac
prio
"rdac" } } multipaths { mulitpath {
device {
vendor DELL
product MD3000i
} } } |
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
