On Tue, Dec 21 at 8:24, Edward Ned Harvey wrote:
From: edmud...@mail.bounceswoosh.org
[mailto:edmud...@mail.bounceswoosh.org] On Behalf Of Eric D. Mudama
On Mon, Dec 20 at 19:19, Edward Ned Harvey wrote:
>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.
Very little is impossible.
Drives have been optimally ordering seeks for 35+ years. I'm guessing
Unless your drive is able to queue up a request to read every single used
part of the drive... Which is larger than the command queue for any
reasonable drive in the world... The point is, in order to be "optimal" you
have to eliminate all those seeks, and perform sequential reads only. The
only seeks you should do are to skip over unused space.
I don't think you read my whole post. I was saying this seek
calculation pre-processing would have to be done by the host server,
and while not impossible, is not trivial. Present the next 32 seeks
to each device while the pre-processor works on the complete list of
future seeks, and the drive will do as well as possible.
If you're able to sequentially read the whole drive, skipping all the unused
space, then you're guaranteed to complete faster (or equal) than either (a)
sequentially reading the whole drive, or (b) seeking all over the drive to
read the used parts in random order.
Yes, I understand how that works.
--eric
--
Eric D. Mudama
edmud...@mail.bounceswoosh.org
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
