Hannes,
nothing that looks really bedrohlich in the
syslog.
What I have done:
9:47 multipathd -v 6 started
9:50 2:0:0:0 and 1:0:1:0 blocked (both paths to
SP-A of the SAN)
9:52 2:0:0:0 and 1:0:1:0 re-enabled
I have attached my syslog.
I am on a gentoo with multipath 0.4.7
(Gerald)
----- Original Message -----
Sent: Thursday, October 18, 2007 9:12
AM
Subject: Re: multibus /
failover and EMC CX600
On Thu, Oct 18, 2007 at 08:55:52AM +0200, Gerald Nowitzky
wrote: > Hannes, > > so is this behavior by design? In this
case, patching in the scsi subsystem won't > help to much, will
it? > No, not really. > Manually updating the
multipath information - well, yes, that will work I guess, > but in the
end that should work without manual intervention. Thus, I'd need to
have > a job checking the multipath table if there are stale devices,
and, if there are, > rerun multipath to get them out. Not exactly
smooth, is it? > Why, we do have interns for this kind of work
:-)
No, really: Normally this should be done by multipathd / udev. With
the mainline multipathd it reads from the kernel netlink socket and will
get a uevent if a device is removed. And it should update the tables
accordingly.
There have been problems with device-mapper itself (older
versions required to flush all outstanding I/O before the table could be
modified), but that should be resolved by now.
So maybe have
multipathd running in verbose mode (ie -v 6 or somesuch) and see what's
going on. Especially why it isn't updating the device-mapper
tables.
BTW, which distribution are you running? multipath & udev
seem to be a tricky area for most.
Not ours, of course
:-)
Cheers,
Hannes -- Dr. Hannes Reinecke
zSeries & Storage hare@xxxxxxx +49
911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nrnberg GF:
Markus Rex, HRB 16746 (AG Nrnberg)
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
|