Linux Device Mapper development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox