public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Christie <mikenc@us.ibm.com>
To: "Philip R. Auld" <pauld@egenera.com>
Cc: James Bottomley <James.Bottomley@steeleye.com>,
	Simon Kelley <simon@thekelleys.org.uk>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: Is there a grand plan for FC failover?
Date: Wed, 28 Jan 2004 14:37:28 -0800	[thread overview]
Message-ID: <401839A8.307@us.ibm.com> (raw)
In-Reply-To: <20040128130040.E11527@vienna.EGENERA.COM>

Philip R. Auld wrote:
> Hi James,
> 	Thanks for the reply. 
> 
> Rumor has it that on Wed, Jan 28, 2004 at 10:57:29AM -0600 James Bottomley said:
> 
>>On Wed, 2004-01-28 at 09:02, Philip R. Auld wrote:
>>
>>>	1) load balancing when possible: it's not enough to be just a 
>>>		failover mechanism.
>>
>>For first out, a failover target supplies most of the needs.  Nothing
>>prevents an aggregation target being added later, but failover is
>>essential.
> 
> 
> Yes, failover is necessary, but not sufficient to make a decent multipath driver.
> I'm a little concerned by the "added later" part. Shouldn't it be designed in? 

The DM multipath can do both. Unfortunately, some work still needs to be 
done. For example, when doing load balancing how much IO to send down 
each path is an issue that the DM maintainer had asked for feedback on. 
Suggestions?

> 
>>>        2) requiring a userspace program to execute for failover is 
>>>	problematic when it could be the root disk that needs 
>>>	failing over.
>>
>>Userspace is required for *configuration* not failover.  The path
>>targets failover automatically as they see I/O down particular paths
>>timing out or failing.  That being said, nothing prevents async
>>notifications via hotplug also triggering a failover (rather than having
>>to wait for timeout etc) but it's not required.
>>
> 
> 
> There was some discussion about vendor plugins to do proprietary failover
> when needed. Say to make a passive path active. My concern is that this be
> memory resident and that we not have to go to the disk for such things.
> 
> If there is no need for that or it's done in such a way that it doesn't need
> the disk this won't be a problem then.
>  

This is something both MD and DM multiapth are not yet fully prepared for.



  parent reply	other threads:[~2004-01-28 22:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-26 14:18 Is there a grand plan for FC failover? Simon Kelley
2004-01-26 15:37 ` James Bottomley
2004-01-28 15:02   ` Philip R. Auld
2004-01-28 16:57     ` James Bottomley
2004-01-28 18:00       ` Philip R. Auld
2004-01-28 20:47         ` Patrick Mansfield
2004-01-28 22:14           ` James Bottomley
2004-01-29  0:55             ` Patrick Mansfield
2004-01-30 19:48               ` [dm-devel] " Joe Thornber
2004-01-31  9:30                 ` Jens Axboe
2004-01-31 16:59                   ` Philip R. Auld
2004-01-31 17:42                     ` Jens Axboe
2004-02-12 15:17                       ` Philip R. Auld
2004-02-12 15:28                         ` Arjan van de Ven
2004-02-12 16:03                           ` Philip R. Auld
2004-01-28 22:37         ` Mike Christie [this message]
2004-01-29 15:24           ` Philip R. Auld
2004-01-29 16:00             ` James Bottomley
2004-01-29 23:25               ` Mike Christie
  -- strict thread matches above, loose matches on Subject: below --
2004-01-28 21:02 Smart, James
2004-01-28 22:16 ` James Bottomley
2004-01-29 14:49   ` Philip R. Auld
2004-01-29 15:05     ` James Bottomley
2004-01-29 17:35 Smart, James
2004-01-29 18:31 ` Mike Anderson
2004-01-29 18:31 ` James Bottomley
2004-01-29 18:41 Smart, James
2004-01-29 19:37 Smart, James

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=401839A8.307@us.ibm.com \
    --to=mikenc@us.ibm.com \
    --cc=James.Bottomley@steeleye.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=pauld@egenera.com \
    --cc=simon@thekelleys.org.uk \
    /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