Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Dec 2001 23:41:51 +0100
From:      Wilko Bulte <wkb@freebie.xs4all.nl>
To:        Greg Lehey <grog@FreeBSD.org>
Cc:        Matthew Dillon <dillon@apollo.backplane.com>, Mike Smith <msmith@FreeBSD.org>, Terry Lambert <tlambert2@mindspring.com>, Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, freebsd-current@FreeBSD.org
Subject:   Re: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c)
Message-ID:  <20011211234151.A72046@freebie.xs4all.nl>
In-Reply-To: <20011212090034.C67986@monorchid.lemis.com>; from grog@FreeBSD.org on Wed, Dec 12, 2001 at 09:00:34AM %2B1030
References:  <200112101754.fBAHsRV01202@mass.dis.org> <200112101813.fBAIDKo47460@apollo.backplane.com> <20011210192251.A65380@freebie.xs4all.nl> <200112101830.fBAIU4w47648@apollo.backplane.com> <20011211110633.M63585@monorchid.lemis.com> <20011211153437.A69755@freebie.xs4all.nl> <20011212090034.C67986@monorchid.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 12, 2001 at 09:00:34AM +1030, Greg Lehey wrote:
> On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote:
> > On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote:
> >> On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote:
> >>>

..

> >>>     and will go down the drain for reads if you cross a stripe -
> >>>     something that is quite common I think.
> >>
> >> I think this is what Mike was referring to when talking about parity
> >> calculation.  In any case, going across a stripe boundary is not a
> >> good idea, though of course it can't be avoided.  That's one of the
> >> arguments for large stripes.
> >
> > In a former life I was involved with a HB striping product for SysVr2
> > that had a slightly modified filesystem that 'knew' when it was
> > working on a striped disk. And as it know, it avoided posting I/O s
> > that crossed stripes.
> 
> So what did it do with user requests which crossed stripes?

Memory is dim, but I think the fs code created a second i/o to the
driver layer. So the fs never sent out an i/o that the driver layer had
to break up. In case of a pre-fetch while reading I think the f/s 
would just pre-fetch until the stripe border and not bother sending
out a second i/o down. 

In the end all of this benchmarked quite favorably.
Note that this was 386/486 era, with the classic SysV filesystem.

-- 
|   / o / /_  _   		email: 	wilko@FreeBSD.org
|/|/ / / /(  (_)  Bulte		Arnhem, The Netherlands	

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011211234151.A72046>