[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] Losing paths
- From: "Daniel Keisling" <daniel keisling austin ppdi com>
- To: <dm-devel redhat com>
- Subject: Re: [dm-devel] Losing paths
- Date: Tue, 22 Jul 2008 11:21:53 -0500
FWIW, I have the
same issue under an HP EVA8000. I'm not really certain if directio is a
solution as I have only seen the tur checker being used with an
EVA.
Daniel
---------------------------------------------------------------------------------------------
Hi
John,
Romanowski, John
(OFT) wrote:
> Hi,
> We had similar problem last year using sles9
and SVC 4.2.0.2, as you describe: adding/deleting a LUN causes
>
brief path failures for the host's remaining, unaffected LUNs.
>
>
We were using tur checker and it turned out that while adding/deleting a LUN
(and some other admin tasks)
> the SVC does not respond well to
test-unit-ready tur requests; but it responds perfectly well to normal
read
> commands. I opened IBM PMR 43118 on that if you want to ask the SVC
folks about it.
>
> Workaround for us was to use readsector0
instead of tur as multipath path checker.
>
> Recent
post here (see July 8, 2008) said multipath-tools is deprecating
readsector0, and to use directio as
> path checker, but directio was said
to be much slower than tur, implying tur was better replacement than
>
directio for readsector0.
>
Only for those cases where no actual
read-access is necessary.
> Not sure what deprecating
readsector0 means for us SVC users.
>
It means you should be
using directio there.
Thanks for the
information, I'll see to have it included in SLES10.
Cheers,
Hannes
--
Dr.
Hannes Reinecke zSeries &
Storage
hare suse de
+49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409
Nürnberg
GF: Markus Rex, HRB 16746 (AG
Nürnberg)
______________________________________________________________________
This email transmission and any documents, files or previous email
messages attached to it may contain information that is confidential or
legally privileged. If you are not the intended recipient or a person
responsible for delivering this transmission to the intended recipient,
you are hereby notified that you must not read this transmission and
that any disclosure, copying, printing, distribution or use of this
transmission is strictly prohibited. If you have received this transmission
in error, please immediately notify the sender by telephone or return email
and delete the original transmission and its attachments without reading
or saving in any manner.
|
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]