DragonFly BSD
DragonFly users List (threaded) for 2005-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: More on vinum woes

From: Chris Csanady <csanady@xxxxxxxxx>
Date: Tue, 13 Sep 2005 15:04:01 -0500

On 9/13/05, Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:
>     True to a degree, but I think software raid is even worse.  Machines
>     evolve, and new ATA chipsets come along which we might not support,
>     or might not support reliably.... just look at all the bug reports
>     FreeBSD gets related to ATA chipsets, and we aren't any better since
>     our ATA code is essentially the same.  Nor is linux.  Even windoz
>     boxes often have issues requiring BIOS upgrades or driver upgrades.
>     DMA issues and actual data corruption can occur quite easily.  The
>     fact that data corruption can occur so easily with these ATA chipsets
>     scares me.

I know it may be too early to tell, but what is the outlook for SATA?  It looks
like several chipset vendors are moving toward the AHCI standard, so
perhaps this mess can be avoided it the future.  In any case, it would
definately be good to have support for NCQ; is anyone working on this?

Hardware raid is nice, but difficult to justify for a simple mirror, or raid-10
setup.  Actually, the raid-10 example in the vinum man page gave me an
idea.  If you stripe across all drives, and mirror to the second half of the
same drives, there are some interesting side effects.  The outer half of the
drive will span less than half the width of the platters, while providing the
best transfer rates.  Having the volume prefer reads from this plex should
reducing average seek times, and increase read performance significantly.
Writes would be somewhat less optimal than a standard raid-10, but with
a fairly large stripe size, should be fine.  It seems like it would be a great
configuration for a read-heavy workload, has anyone tried this?

(btw, later in the man page, it states that reversing the subdisk order in
that example is for performance reasons.  this is silly; what good would a
raid be if the data was mirrored onto the same disk?  also, i think
sequential writes would work better if the subdisk ordering was offset by
2 rather than reversed.)


PS The offending portion of vinum.8, if someone wants to correct it:

     o   Mirroring decreases performance for all writes, whether multi-access
         or single access, since the data must be written to both plexes.
         This explains the subdisk layout in the example of a mirroring con-
         figuration above: if the corresponding subdisk in each plex is on a
         different physical disk, the write commands can be issued in paral-
         lel, whereas if they are on the same physical disk, they will be per-
         formed sequentially.

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]