[dm-devel] Losing paths

[Daniel Keisling]

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
 
 
---------------------------------------------------------------------------------------------
Date: Tue, 22 Jul 2008 16:55:27 +0200
From: Hannes Reinecke <hare at suse.de>
Subject: Re: [dm-devel] Losing paths
To: device-mapper development <dm-devel at redhat.com>
Message-ID: <4885F4DF.8010000 at suse.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 
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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20080722/6a39ea21/attachment.htm>