Richard Elling wrote:
Erik Trimble wrote:
All this discussion hasn't answered one thing for me: exactly _how_
does ZFS do resilvering? Both in the case of mirrors, and of RAIDZ[2] ?
I've seen some mention that it goes in cronological order (which to
me, means that the metadata must be read first) of file creation, and
that only used blocks are rebuilt, but exactly what is the
methodology being used?
See Jeff Bonwick's blog on the topic
http://blogs.sun.com/bonwick/entry/smokin_mirrors
-- richard
That's very informative. Thanks, Richard.
So, ZFS walks the used block tree to see what still needs rebuilding.
I guess I have two related questions then:
(1) Are these blocks some fixed size (based on the media - usually 512
bytes), or are they "ZFS blocks" - the fungible size based on the
requirements of the original file size being written?
(2) is there some reasonable way to read in multiples of these blocks in
a single IOP? Theoretically, if the blocks are in chronological
creation order, they should be (relatively) sequential on the drive(s).
Thus, ZFS should be able to read in several of them without forcing a
random seek. That is, you should be able to get multiple blocks in a
single IOP.
If we can't get multiple ZFS blocks in one sequential read, we're
screwed - ZFS is going to be IOPS bound on the replacement disk, with no
real workaround. Which means rebuild times for disks with lots of small
files is going to be hideous.
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
