> Robert Milkowski wrote: > > Hello Mario, > > > > Wednesday, May 9, 2007, 5:56:18 PM, you wrote: > > > > MG> I've read that it's supposed to go at full speed, i.e. as fast as > > MG> possible. I'm doing a disk replace and what zpool reports kind of > > MG> surprises me. The resilver goes on at 1.6MB/s. Did resilvering get > > MG> throttled at some point between the builds, or is my ATA controller hav > ing bigger issues? > > > > Lot of small files perhaps? What kind of protection have you used? > > Good question. Remember that resilvering is done in time order and from > the top-level metadata down, not by sequentially blasting bits. Jeff > Bonwick describes this as top-down resilvering. > http://blogs.sun.com/bonwick/entry/smokin_mirrors > > From a MTTR and performance perspective this means that ZFS recovery time > is a function of the amount of space used, where it is located (!), and the > validity of the surviving or regenerated data. The big win is the amount of > space used, as most file systems are not full. > -- richard
It seems to me that once you copy meta data, you can indeed copy all live data sequentially. Given that a vast majority of disk blocks in use will typically contain data, this is a winning strategy from a performance point of view and still allows you to retrieve a fair bit of data in case of a second disk failure (checksumming will catch a case where good metadata points to as yet uncopied data block). If amount of live data is > 50% of disk space you may as well do a disk copy, perhaps skipping over already copied meta data. Not only that, you can even start using the disk being resilvered right away for writes, The new write will be either to a) an already copied block or b) as yet uncopied block. In case a) there is nothing more to do. In case b) the copied-from-block will have the new data so in both cases the right thing happens. Any potential window between reading a copied-from block and writing to copied-to block can be closed with careful coding/locking. If a second disk fails during copying, the current strategy doesn't buy you much in most any case. You really don't want to go through a zillion files looking for survivors. If you have a backup, you will restore from that rather than look through the debris. Not to mention you have made the window of a potentially catastrophic failure much larger if resilvering is significantly slower. Comments? _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
