All of lore.kernel.org
 help / color / mirror / Atom feed
From: guy keren <choo@actcom.co.il>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: Losing paths
Date: Wed, 23 Jul 2008 01:10:58 +0300	[thread overview]
Message-ID: <48865AF2.8090000@actcom.co.il> (raw)
In-Reply-To: <65F9ACC78BD8304BAAEB817634C62D4C060CFB67@AUSMAIL01.americas.ppdi.local>


Does the 'tur' checker take into account unit-attention issues (i.e. 
when the configuration of a SCSI device changes, the next command coming 
from an afected initiator (not necessarily to the same LU) should be 
failed with a 'check condition' error and a 'unit attention' sense code.

if the TUR checker sent a TUR right after the change and before another 
read/write command was sent - it will be failed, and then the question 
is, whether the lower-level driver retries the TUR command, or returns 
an error. any idea?

--guy

Daniel Keisling wrote:
> 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@suse.de <mailto:hare@suse.de>>
> Subject: Re: [dm-devel] Losing paths
> To: device-mapper development <dm-devel@redhat.com 
> <mailto:dm-devel@redhat.com>>
> Message-ID: <4885F4DF.8010000@suse.de <mailto:4885F4DF.8010000@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@suse.de <mailto: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.
> 
> 
> ------------------------------------------------------------------------
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

  reply	other threads:[~2008-07-22 22:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-22 16:21 Losing paths Daniel Keisling
2008-07-22 22:10 ` guy keren [this message]
2008-07-23  6:25   ` Hannes Reinecke
  -- strict thread matches above, loose matches on Subject: below --
2008-08-26  7:33 Vardaris, C - SPLXM
2008-07-22 11:22 Vardaris, C - SPLXM
2008-07-22 14:44 ` Romanowski, John (OFT)
2008-07-22 14:55   ` Hannes Reinecke
2008-07-23  8:44   ` Vardaris, C - SPLXM
2008-07-23 12:33     ` Koehler, M - SPLXM
2008-07-23 13:12       ` Romanowski, John (OFT)
2008-07-23 13:22         ` Koehler, M - SPLXM
2008-07-23 17:00           ` Pradipmaya Maharana
2008-07-23 17:02           ` Romanowski, John (OFT)
2008-07-23 22:32             ` Menno Koehler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48865AF2.8090000@actcom.co.il \
    --to=choo@actcom.co.il \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.