All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Mike Christie <michaelc@cs.wisc.edu>
Cc: device-mapper development <dm-devel@redhat.com>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [dm-devel] LSF: Multipathing and path checking question
Date: Tue, 21 Apr 2009 09:26:27 +0200	[thread overview]
Message-ID: <49ED7523.5080108@suse.de> (raw)
In-Reply-To: <49ECFF0F.5080003@cs.wisc.edu>

Mike Christie wrote:
> Mike Christie wrote:
>>> For starters we just should send a netlink event when fast_fail_io has
>>> fired. We could easily integrate that one in multipathd and would gain
>>> an instant benefit from that as we can switch paths in advance.
>>> Next step would be to implement an additional sdev state which would
>>> return 'DID_TRANSPORT_FASTFAIL' for any 'normal' I/O; it would be
>>> inserted between 'RUNNING' and 'CANCEL'.
>>> Transition would be possible between 'RUNNING' and 'FASTFAIL', but
>>> it would only be possible to transition into 'CANCEL' from 'FASTFAIL'.
>>>
>>
>>
>> Yeah, a new sdev state might be nice. Right now this state is handled
>> by the classes. For iscsi and FC the port/session will be in
>> blocked/ISCSI_SESSION_FAILED. Then internally the classes are
>> decieding what to do with IO in the *_chkready functions.
>>
>>
> 
> 
> How about setting the device to the offline state for this case where
> fast_io_fail has fired but the dev_loss_tmo has not yet fired? As fast
> as failing IO we get the same result. scsi-ml would fail the incoming IO
> instead of it getting to the class _chkready functions, but the scsi
> device state indicates that it cannot execute IO which might be nice for
> users.
> 
Ah, no. OFFLINE is a dead end status out of which we cannot transition
from inside the kernel. I'd prefer a new state here.

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)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2009-04-21  7:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-16 22:59 LSF: Multipathing and path checking question Mike Christie
2009-04-17  7:50 ` [dm-devel] " Hannes Reinecke
2009-04-17 14:55   ` Mike Christie
2009-04-17 15:21     ` Mike Christie
2009-04-20  8:19       ` [dm-devel] " Hannes Reinecke
2009-04-20 19:23         ` Mike Christie
2009-04-20 23:02           ` Mike Christie
2009-04-21  7:26             ` Hannes Reinecke [this message]
2009-04-20  7:59     ` [dm-devel] " Hannes Reinecke
2009-04-20 19:10       ` Mike Christie
2009-04-20 19:28         ` [dm-devel] " Mike Christie
2009-04-21  7:04           ` Hannes Reinecke

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=49ED7523.5080108@suse.de \
    --to=hare@suse.de \
    --cc=dm-devel@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michaelc@cs.wisc.edu \
    /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.