On Wed, Dec 30, 2009 at 12:35 PM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > On Tue, 29 Dec 2009, Ross Walker wrote: >> >>> Some important points to consider are that every write to a raidz vdev >>> must be synchronous. In other words, the write needs to complete on all the >>> drives in the stripe before the write may return as complete. This is also >>> true of "RAID 1" (mirrors) which specifies that the drives are perfect >>> duplicates of each other. >> >> I believe mirrored vdevs can do this in parallel though, while raidz vdevs >> need to do this serially due to the ordered nature of the transaction which >> makes the sync writes faster on the mirrors. > > I don't think that the raidz needs to write the stripe serially, but it does > need to ensure that the data is committed to the drives before considering > the write to be completed. This is due to the nature of the RAID5 stripe, > which needs to be completely written. It seems that mirrors are more sloppy > in that writing and committing to one mirror is enough.
Ok, that makes sense, as long as the metadata is committed, which can happen for mirrors as soon as one side is written, but not for raidz until the whole stripe is written. So accurate in the increased latency for raidz, but for the wrong reason. >> Bob, an interesting question was brought up to me about how copies may >> affect random read performance. I didn't know the answer, but if ZFS knows >> there are additional copies would it not also spread the load across those >> as well to make sure the wait queues on each spindle are as even as >> possible? > > Previously we were told that zfs uses a semi-random algorithm to select > which mirror side (or copy) to read from. Presumably more (double) > performance would be available if zfs was able to precisely schedule and > interleave reads from the mirror devices, but perfecting that could be quite > challenging. With mirrors, we do see more read performance than one device > can provide, but we don't see double. That isn't quite what I was getting at. Say one has a pool of mirrors, then they set copies=2 on the pool, which in theory should create a second copy of the data on another vdev in the pool. If during servicing a read request, is the ZFS scheduler smart enough to read from the second copy if the vdev where the first copy lies is being serviced by another read/write request? If so this would increase the read performance of the pool of mirrors by sacrificing some write performance. -Ross _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
