On Dec 29, 2009, at 9:16 AM, Brad wrote:
@eric
"As a general rule of thumb, each vdev has the random performance
roughly the same as a single member of that vdev. Having six RAIDZ
vdevs in a pool should give roughly the performance as a stripe of six
bare drives, for random IO."
This model begins to break down with raidz2 and further breaks down
with raidz3. Since I wrote about this simple model here:
http://blogs.sun.com/relling/entry/zfs_raid_recommendations_space_performance
we've refined it a bit, to take into account the number of parity
devices.
For small, random read IOPS the performance of a single, top-level
vdev is
performance = performance of a disk * (N / (N - P))
where,
N = number of disks in the vdev
P = number of parity devices in the vdev
For example, using 5 disks @ 100 IOPS we get something like:
2-disk mirror: 200 IOPS
4+1 raidz: 125 IOPS
3+2 raidz2: 167 IOPS
2+3 raidz3: 250 IOPS
Once again, it is clear that mirroring will offer the best small,
random read
IOPS.
It sounds like we'll need 16 vdevs striped in a pool to at least get
the performance of 15 drives plus another 16 mirrored for redundancy.
If we are bounded in iops by the vdev, would it make sense to go
with the bare minimum of drives (3) per vdev?
"This winds up looking similar to RAID10 in layout, in that you're
striping across a lot of disks that each consists of a mirror, though
the checksumming rules are different. Performance should also be
similar, though it's possible RAID10 may give slightly better random
read performance at the expense of some data quality guarantees, since
I don't believe RAID10 normally validates checksums on returned data
if the device didn't return an error. In normal practice, RAID10 and
a pool of mirrored vdevs should benchmark against each other within
your margin of error."
That's interesting to know that with ZFS's implementation of raid10
it doesn't have checksumming built-in.
ZFS always checksums everything unless you explicitly disable
checksumming for data. Metadata is always checksummed.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
