FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

LinkBack Thread Tools
Old 12-14-2007, 08:44 AM
Default device-errors and multipath device access issue

<devzero <at> web.de> writes:

> Hello !
> we are using multipath on sles9 and access those devices via
> on boot, we get lot`s of error messages like
> > Aug 28 10:30:16 rac02 kernel: Device sdf not ready.
> > Aug 28 10:30:16 rac02 kernel: end_request: I/O error, dev sdf, sector 513680
> > Aug 28 10:30:16 rac02 kernel: Buffer I/O error on device sdf, logical block
> > Aug 28 10:30:16 rac02 kernel: Buffer I/O error on device sdf, logical block
> > Aug 28 10:30:16 rac02 kernel: Buffer I/O error on device sdf, logical block
> for each alternative path to a lun.
> 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.

Hello Roland,

I got the same problem using Sles9SP3 with a newer Kernel on a FSC TX300-Server,
this one is connected to an san using a volume-Manager, Multipathsoftware and
so on.
After reading your hint with the monitoring software I stopped the FSC
serveragent-daemons and the messages with the Buffer I/O error are gone.
In combination with lvm2-organized disks on a second TX300 I got something like
that you described second - I have to test it again (specially the boot-process,
maybe this can solved for me using a other naming scheme for the san-luns).

So, I don't know if it is helpful for you:
you're right with the monitoring-software I think (I will discuss this for me
with the FSC-guys) but: are there all SAN-Luns in the messages file (it is in my
I disconnected step by step one of the both FC-Paths, but on my TX300 the errors
still continued, and in that situation there where no second path to the san.
So, I'm not sure if that can be the reason in your situation.

If I got some new Information I will let you now, if you solved your problem:
please let me know.



dm-devel mailing list

Thread Tools

All times are GMT. The time now is 09:30 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org