[dm-devel] Re: Is there a grand plan for FC failover?
Philip R. Auld
pauld at egenera.com
Fri Feb 13 09:26:00 UTC 2004
Rumor has it that on Sat, Jan 31, 2004 at 06:42:01PM +0100 Jens Axboe said:
> On Sat, Jan 31 2004, Philip R. Auld wrote:
> > Rumor has it that on Sat, Jan 31, 2004 at 10:30:37AM +0100 Jens Axboe said:
> > > On Fri, Jan 30 2004, Joe Thornber wrote:
> > > > 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).
> >
> > Out of curiosity, where does raw io fit into that in 2.6?
>
> raw io (or O_DIRECT io, same path) should work even better, always send
> out bio's as big as the underlying device can support.
>
That size is based on the blocksize? Is there a way to set the block size higher than
512 w/o mounting it? I've gotten really bad rawio performance on 2.4. since I have a
limit of 32 sg entries. When Rawio uses a 512 byte blocksize IOs are limited to 16K.
Will this still be a problem in 2.6?
Thanks again,
Phil
> --
> Jens Axboe
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Philip R. Auld, Ph.D. Egenera, Inc.
Principal Software Engineer 165 Forest St.
(508) 858-2628 Marlboro, MA 01752
More information about the dm-devel
mailing list