All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Joe Thornber <thornber@redhat.com>
Cc: dm-devel@sistina.com,
	James Bottomley <James.Bottomley@steeleye.com>,
	"Philip R. Auld" <pauld@egenera.com>,
	Simon Kelley <simon@thekelleys.org.uk>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [dm-devel] Re: Is there a grand plan for FC failover?
Date: Sat, 31 Jan 2004 10:30:37 +0100	[thread overview]
Message-ID: <20040131093037.GR11683@suse.de> (raw)
In-Reply-To: <20040130194826.GC31596@reti>

On Fri, Jan 30 2004, Joe Thornber wrote:
> On Wed, Jan 28, 2004 at 04:55:34PM -0800, Patrick Mansfield wrote:
> > > We had the "where does the elevator go" discussion at the OLS bof.  I
> > > think I heard agreement that the current situation of between dm and
> > > block is suboptimal and that we'd like a true coalescing elevator above
> > > dm with a vestigial one for the mid-layer to use for queueing below.  I
> > > think this is a requirement for dm multipath to work well, but it's not
> > > a requirement for it actually to work.
> > 
> > If the performance is bad enough, it doesn't matter if it works.
> 
> It would be great to get some benchmarks to back up these arguments.
> eg, performance of dm mpath with a simple round robin selector,
> compared to a scsi layer implementation.  Lifting the elevator (or
> lowering dm) is a big piece of work that I wont even consider unless
> there is very good reason; the reason probably needs to be broader
> than just multipath too.  Even if we did decide to do this, it won't
> happen in 2.6.

I suspect the problem really isn't that huge in 2.6, since most
performance file systems are using mpage or building their own big
bio's. So in a sense, some of the merging already does happen above dm
(and the io scheduler).

-- 
Jens Axboe


  reply	other threads:[~2004-01-31  9:31 UTC|newest]

Thread overview: 19+ 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 [this message]
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
2004-01-29 15:24           ` Philip R. Auld
2004-01-29 16:00             ` James Bottomley
2004-01-29 23:25               ` Mike Christie

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=20040131093037.GR11683@suse.de \
    --to=axboe@suse.de \
    --cc=James.Bottomley@steeleye.com \
    --cc=dm-devel@sistina.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=pauld@egenera.com \
    --cc=simon@thekelleys.org.uk \
    --cc=thornber@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.