> From: Richard Elling [mailto:richard.ell...@gmail.com] > > > This is one of the reasons the raidzN resilver code is inefficient. > > Since you end up waiting for the slowest seek time of any one disk in > > the vdev, and when that's done, the amount of data you were able to > > process was at most 128K. Rinse and repeat. > > How is this different than all other RAID implementations?
Hardware raid has the disadvantage that it must resilver the whole disk regardless of how much of the disk is used. Hardware raid has the advantage that it will resilver sequentially, so despite the fact that it resilvers unused space, it is limited by sustainable throughput instead of random seek time. The resilver time for hardware raid is a constant regardless of what the OS has done with the disks over time (neglecting system usage during resilver.) If your ZFS vdev is significantly full, with data that was written, and snapshotted, and rewritten, and snapshots destroyed, etc etc etc ... Typical usage for a system that has been in production for a while ... then the time to resilver the whole disk block-by-block will be lower than the time to resilver the used portions in order of allocation time. This is why sometimes the ZFS resilver time for a raidzN can be higher than the time to resilver a similar hardware raid. As evidenced by the frequent comments & complaints on this list about raidzN resilver time. Let's crunch some really quick numbers here. Suppose a 6Gbit/sec sas/sata bus, with 6 disks in a raid-5. Each disk is 1TB, 1000G, and each disk is capable of sustaining 1 Gbit/sec sequential operations. These are typical measurements for systems I use. Then 1000G = 8000Gbit. It will take 8000 sec to resilver = 133min. So whenever people have resilver times longer than that ... It's because ZFS resilver code for raidzN is inefficient. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
