UNIX admin wrote:
This is simply not true. ZFS would protect against
the same type of
errors seen on an individual drive as it would on a
pool made of HW raid
LUN(s). It might be overkill to layer ZFS on top of a
LUN that is
already protected in some way by the devices internal
RAID code but it
does not "make your data susceptible to HW errors
caused by the storage
subsystem's RAID algorithm, and slow down the I/O".
I disagree, and vehemently at that. I maintain that if the HW RAID is used, the
chance of data corruption is much higher, and ZFS would have a lot more
repairing to do than it would if it were used directly on disks. Problems with
HW RAID algorithms have been plaguing us for at least 15 years or more. The
venerable Sun StorEdge T3 comes to mind!
Please expand on your logic. Remember that ZFS works on top of LUNs. A
disk drive by itself is a LUN when added to a ZFS pool. A LUN can also
be comprised of multiple disk drives striped together and presented to a
host as one logical unit. Or a LUN can be offered by a virtualization
gateway that in turn imports raid array LUNs that are really made up of
individual disk drives. Or ... insert a million different ways to get a
host something called a LUN that allows the host to read and write
blocks. They could be really slow LUNs because they're two hamsters
shuffling zeros and ones back and forth on little wheels. (OK, that
might be too slow.) Outside of the cache enabling when entire disk
drives are presented to the pool ZFS doesn't care what the LUN is made of.
ZFS reliability features are available and work on top of the LUNs you
give it and the configuration you use. The type of LUN is
inconsequential at the ZFS level. If I had 12 LUNS that were single disk
drives and created a RAIDZ pool it would have the same reliability at
the ZFS level as if I presented it 12 LUNs that were really quad-mirrors
from 12 independent hw raid array. You can make argument that the 12
disk drive config is easier to use or that the overall reliability of
the 12 quad-mirror LUNs system has a higher reliability but at ZFSs
point of view it's the same. Its happily writing blocks, checking
checksums, reading things from the LUNs, etc. etc. etc.
On top of that disk drives are not some simple beast that just coughs up
i/o when you want it to. A modern disk drive does all sorts of stuff
under the covers to speed up i/o and - surprise - increase the
reliability of the drive as much as possible. If you think you're really
writing "straight to disk" you're not. Cache, ZBR, bad block
re-allocation, all come into play.
As for problems with specific raid arrays, including the T3, you are
preaching to the choir but I'm definitely not going to get into a
pissing contest over specific components having more or less bugs then
an other.
Further, while it is perfectly logical to me that doing RAID calculations twice
is slower than doing it once, you maintain that is not the case, perhaps
because one calculation is implemented in FW/HW?
As the man says, "It depends". A really fast raid array might be
responding to i/o requests faster then a single disk drive. It might not
given the nature of the i/o coming in.
Don't think of it in terms of RAID calculations taking a certain amount
of time. Think of it in terms of having to meet a specific amount of
requirements to manage your data. I'll be the first to say that if
you're going to be putting ZFS on a desktop then a simple JBOD is a box
to look at. If you're going to look at an enterprise data center the
answer is going to be different. That is something a lot of people on
this alias seem to be missing out on. Stating ZFS on JBODs is the answer
to everything is the punchline of the "When all you have is a hammer..."
routine.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
