On Thu, 26 Jun 2008, Peter T. Breuer wrote:
> "Also sprach Merlin Moncure:"
>> The linux software raid algorithms are highly optimized, and run on a
> I can confidently tell you that that's balderdash both as a Linux author
> and as a software RAID linux author (check the attributions in the
> kernel source, or look up something like "Raiding the Noosphere" on
>> presumably (much faster) cpu than what the controller supports.
>> However, there is still some extra oomph you can get out of letting
>> the raid controller do what the software raid can't...namely delay
>> sync for a time.
> There are several design problems left in software raid in the linux kernel.
> One of them is the need for extra memory to dispatch requests with and
> as (i.e. buffer heads and buffers, both). bhs should be OK since the
> small cache per device won't be exceeded while the raid driver itself
> serialises requests, which is essentially the case (it does not do any
> buffering, queuing, whatever .. and tries hard to avoid doing so). The
> need for extra buffers for the data is a problem. On different
> platforms different aspects of that problem are important (would you
> believe that on ARM mere copying takes so much cpu time that one wants
> to avoid it at all costs, whereas on intel it's a forgettable trivium).
> I also wouldn't aboslutely swear that request ordering is maintained
> under ordinary circumstances.
which flavor of linux raid are you talking about (the two main families I
am aware of are the md and dm ones)
In response to
pgsql-performance by date
|Next:||From: kevin kempter||Date: 2008-06-26 20:33:51|
|Subject: Federated Postgresql architecture ?|
|Previous:||From: Merlin Moncure||Date: 2008-06-26 20:01:34|
|Subject: Re: Hardware vs Software Raid|