Compaq Smart Array 3200 Controller as a SCSI Controller
cctalk at gtaylor.tnetconsulting.net
Thu Jul 16 12:21:36 CDT 2020
On 7/16/20 9:52 AM, Ali via cctalk wrote:
> I have never used a SW RAID solution (except for a RAID 0 on Win2K3 for
> the boot drive)
Are you sure that was RAID 0 (zero), /striping/? I've never heard of
/software/ RAID 0 (striping) for the /boot/ drive in Windows. I would
expect that to be RAID 1 or something other than the drive with
NTLDR.EXE on it. I also suspect that the drive with %SystemRoot% on it
would need to more conducive to loading driver and software RAID support
files very early in the boot process.
> and have used HW controllers in my more recent systems (I am particular
> to the Areca Controllers - cheap but effective with a good feature
I've completely lost track of hardware RAID controllers. I'm now more
interested in I.T. HBA controllers to use with ZFS based software RAID.
> What I find problematic with RAID (specially RAID 6) is that with
> the larger drives we have in use today build (or more importantly
> rebuild/recovery) times are extremely long. Long enough that you
> could have a second drive failure during that time based on statistics.
That's one of the reasons that ZFS supports three drives worth of
redundancy in addition to the data space. RAID Z1 / Z2 / Z3.
I think we are quickly getting to the point, if not past it, where a
/single/ RAID array can't safely hold the entirety of the necessary
storage. Instead, I see multiple smaller RAID arrays aggregated
together at a higher layer.
I've seen this done by striping / JBODing / LVMing / etc. multiple
discrete RAID arrays together in the OS.
ZFS natively does this by striping (RAID 0) across multiple underlying
RAID sets (of whatever RAID level you want).
> This is an article (for the layman) written in 2010
> predicting the lack of usability of RAID 6 by 2019:
> www.zdnet.com/article/why-raid-6-stops-working-in-2019/. I found
> the math in it interesting and the conclusions pretty true to my
> I am wondering if SW RAID is faster in rebuild times by now (using the
> full power of the multi-core processors) vs. a dedicated HW controller
> (even one with dual cores).
I think that the CPU overhead / computation time is now largely
insignificant. To me, one of the biggest issues is the simple massing
amount of data that needs to be read from and written to multiple
drives. At full interface speed, some drives can take a LONG time to
transfer all the data. What's worse is the sustained I/O speed to
platters of spinning rust being significantly slower than the interface
This is where some intelligence in the RAID implementation is really
nice. There is very little need to rebuild the yet unused area of a big
RAID array. ZFS shines in this as it only (re)builds the area that has
any data on it. Only have a few hundred GB on that multi TB RAID array
consisteng of multipel 1 TB drives? Fine. Only need to check the few
hundred GB. It's actually quite fast.
Grant. . . .
unix || die
More information about the cctalk