Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Jan 2002 10:12:40 +1030
From:      Greg Lehey <grog@FreeBSD.org>
To:        Bernd Walter <ticso@cicely8.cicely.de>
Cc:        Jason Andresen <jandrese@mitre.org>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: vinum write spanning
Message-ID:  <20020129101240.E92998@wantadilla.lemis.com>
In-Reply-To: <20020128183409.D95936@cicely8.cicely.de>
References:  <3C556517.CED19C80@mitre.org> <20020128183409.D95936@cicely8.cicely.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 28 January 2002 at 18:34:10 +0100, Bernd Walter wrote:
> On Mon, Jan 28, 2002 at 09:49:59AM -0500, Jason Andresen wrote:
>> I'm hoping there is an easy answer to this one...
>>
>> Is there some way vinum can be tickled such that it writes to all disks
>> in a plex at once?  For instance, say I have a 6 disk RAID5 array
>> that I'm writing a 200MB file to.  Is there some way I can make
>> vinum attempt to write data to all of the drive simultaniously?
>
> You can't easily increase performance in a single file access case
> with more disks.  Especialy in the R5 case where you have several
> blocks depend on the same parity.

Well, in fact it's particularly interesting in the RAID-5 case: then
you can write an entire band without having to read first, thus
doubling the throughput.

The problem with this approach is that FreeBSD is currently limited to
an I/O size of 128 kB.  A reasonable stripe size for RAID-5 is 300 kB
or so, so in Jason's example you'd have to be able to issue an I/O
request of 1.5 MB.  Until this is possible, there's no point in
writing the code (which would be possible, though not trivial).

>> If vinum already does that I'm probably just saturating the PCI bus
>> and there's nothing more I can do, but it seems like I should have
>> a tougher time saturating the bus with 5400RPM drives...
>
> Vinum is designed for multiple file access which is a more common
> situation for a unix system.

Well, it tries to be universally useful.  But this particular
optimization doesn't currently make sense.

Greg
--
See complete headers for address and phone numbers

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




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