Johan Hartzenberg wrote:
> There is so much unsupported claims and noise on both sides that 
> everybody is sounding like a bunch of fanboys.

I don't think there are two sides.  Anyone who has been around computing
for any length of time has lost data due to various failures.  The 
question isn't
about losing data, it is about how to proceed when your data is damaged.

>
> The only bit that I understand about why HW raid "might" be bad is 
> that if it had access to the disks behind a HW RAID LUN, then _IF_ zfs 
> were to encounter corrupted data in a read, it will probably be able 
> to re-construct that data.  This is at the cost of doing the parity 
> calculations on a general purpose CPU, and then sending that parity 
> data, as well as the data to write, across the wire.  Some of that 
> cost may be offset against Raid-Z's optimizations over raid-5 in some 
> situations, but all of this is pretty much if-then-maybe type situations.

OK, repeat after me: there is no such thing as hardware RAID, there is no
such thing as hardware RAID, there is no such thing as hardware RAID.
There is only software RAID.  If you believe any software is infallible, 
then
you will be hurt. Even beyond RAID, there is quite sophisticated software
on your disks, and anyone who has had to upgrade disk firmware will
attest that disk firmware is not infallible.

> I also understand that HW raid arrays have some vulnerabilities and 
> weaknesses, but those seem to be offset against ZFS' notorious 
> instability during error conditions.  I say notorious, because of all 
> the open bug reports and reports on the list of I/O hanging and/or 
> systems panicing while waiting for ZFS to realize that something has 
> gone wrong.
>
> I think if this last point can be addressed - make ZFS respond MUCH 
> faster to failures, then it will go a long way to make ZFS  be more 
> readily adopted.

However, you can't respond too fast -- something which seems to get lost
in these conversations.  If you declare a disk dead too fast, then you get
caught in a bind by things like Seagate disks which "freeze" for a few
seconds.  It may be much better to ride through such things than initiate a
reconfiguration action (as described in the article below).
http://blogs.zdnet.com/storage/?p=369&tag=nl.e539

Note: as of b97, it is now possible to set per-device retries in the sd and
ssd drivers. This is a good start towards satisfying those who are
fed up with the default sd/ssd retry logic.  See sd(7d)
http://opensolaris.org/os/community/arc/caselog/2007/505/

 -- richard

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to