> From: Erik Trimble [mailto:erik.trim...@oracle.com] > > We can either (a) change how ZFS does resilvering or (b) repack the > zpool layouts to avoid the problem in the first place. > > In case (a), my vote would be to seriously increase the number of > in-flight resilver slabs, AND allow for out-of-time-order slab > resilvering.
Question for any clueful person: Suppose you have a mirror to resilver, made of disk1 and disk2, where disk2 failed and is resilvering. If you have an algorithm to create a list of all the used blocks of disk1 in disk order, then you're able to resilver the mirror extremely fast, because all the reads will be sequential in nature, plus you get to skip past all the unused space. Now suppose you have a raidz with 3 disks (disk1, disk2, disk3, where disk3 is resilvering). You find some way of ordering all the used blocks of disk1... Which means disk1 will be able to read in optimal order and speed. Does that necessarily imply disk2 will also work well? Does the on-disk order of blocks of disk1 necessarily match the order of blocks on disk2? If there is no correlation between on-disk order of blocks for different disks within the same vdev, then all hope is lost; it's essentially impossible to optimize the resilver/scrub order unless the on-disk order of multiple disks is highly correlated or equal by definition. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
