Re: device-errors and multipath device access issue

[devzero@web.de]

> 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