Peter Schuller wrote:
Is this expected behavior? Assuming concurrent reads (not synchronous and
sequential) I would naively expect an ndisk raidz2 pool to have a
normalized performance of n for small reads.
q.v. http://www.opensolaris.org/jive/thread.jspa?threadID=20942&tstart=0
where such behavior in a hardware RAID array lead to corruption which
was detected by ZFS. No free lunch today, either.
-- richard
I appreciate the advantage of checksumming, believe me. Though I don't see why
this is directly related to the small read problem, other than that the
implementation is such.
Is there some fundamental reason why one could not (though I understand one
*would* not) keep a checksum on a per-disk basis, so that in the normal case
one really could read from just one disk, for a small read? I realize it is
not enough for a block to be self-consistent, but theoretically couldn't the
block which points to the block in question contain multiple checksums for
the various subsets on different disks, rather than just the one checksum for
the entire block?
Then you would need to keep checksums for each physical block, which
is not part of the on-disk spec. It is not clear to me that this
would be a net
win, because you would need that checksum to be physically placed on
another vdev, which implies that you still couldn't just read a single
block and
be happy. Note, there are lots of different possibilities here, ZFS
implements
the end-to-end checksum which would not be replaced by a lower level
checksum anyway.
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
