[dm-devel] device-errors and multipath device access issue
devzero at web.de
devzero at web.de
Wed Nov 14 22:36:10 UTC 2007
> for each alternative path to a lun.
>
>>I assume you mean "for each path to the alternate controller of the volume".
yes, indeed.
>> we also get those messages when the system is up and running because
>> some proprietary monitoring software is checking for device
>> availability in regular intervals and there seems no way to tell that
>> software to skip certain devices - so we get spammed with this
>> messages like this in /var/log/messages and are not able to see the
>> real errors anymore.
>>
>> is there a way to hide those "classic" scsi devices from userspace?
>> i`m not sure if "blacklist" in multipath.conf is what i need here (?)
>> or if i safely could delete those device-nodes - i`m not very deep
>> into multipathing for now.
>
>I don't think you can (without at the same time taking away
>dm-multipath's ability to fail over I/O to those paths...
ok - then i must live with this and hope that proprietary application can be stopped touching these....
>You're not saying which kind of storage hardware this is.
sorry. it`s an EMC Clariion CX500
>Maybe it has a way of being configured in a fake active/active configuration where
>I/O can be processed on both controllers at the same time. I believe
>newer EMC CLARiiON and HP EVA can be set up in ALUA mode which does the
>trick. HDS AMS does something similar which work mostly the same way.
yes - but i don`t think the admin wants to touch such essential configuration to get rid of error messages in the kernel-log....
>You might also be able to filter out those lines from the logs, too. I
>think at least syslog-ng can be made to do that.
ok, but that`s not an elegant way to go....
>> in our case, kpartx doesn`t seem to be launched by udev but from
>> within boot.multipath, but it looks like a timing issue because it
>> sometimes happens and sometimes not.
>>
>> any help or some input (links?docs?) to enlighten me would be highly
>> appreciated
>
>I'd suggest simply not making partitions - make several smaller volumes
>on your storage array instead. That'll make it easier to expand them
>individually if the need should arise, and you won't have to deal with
>kpartx at all. There's always some kind of trouble with it, in my
>experience. Same goes for udev...
meanwhile, i found a novell paper which recommends the same - no partitions and access access /dev/disk instead of /dev/mapper
will discuss moving to a non partitioned scenario.
thanks.
roland
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 3 Monate
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220
More information about the dm-devel
mailing list