[richard tries pushing the rope one more time] On Mar 21, 2011, at 8:40 PM, Edward Ned Harvey wrote:
>> From: Richard Elling [mailto:richard.ell...@gmail.com] >> >> There is no direct correlation between the number of blocks and resilver >> time. > > Incorrect. > > Although there are possibly some cases where you could be bandwidth limited, > it's certainly not true in general. > > If Richard were correct, then a resilver would never take longer than > resilvering an entire disk (including unused space) sequentially. I can prove this to be true for a device that does not suffer from a seek penalty. > The time > to resilver an entire disk sequentially is easily calculated, if you know > the sustained sequential speed of the disk and size of the disk. In my > case, I have a 1TB mirror, where each disk can sustain 1Gbit/sec. Which > means according to Richard, my max resilver time would be 133min. In > reality, my system resilvered in 12 hours while otherwise idle. Bummer, your disk must have some sort of seek penalty... perhaps 8.2 ms? > This can > only be explained one way: As Erik says, the order in which my disks > resilvered is not disk ordered. My disks resilver time was random access > time limited. Not bandwidth limited. I have data that proves the resilver time depends on the data layout and that layout changes as your usage of the pool changes. Like most things in ZFS, it is dynamic. The data proves the resilver time is not correlated to the number of disks in a vdev. The data shows that the resilver time is dependent on the speed of the resilvering disk. I am glad that your experience confirms this. But why does it need to be rehashed every few months on the alias? -- richard
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
