zfs should improve allocation order and throttle allocations
When write I/Os are issued, they are issued in block order but the ZIO pipeline will drive them asynchronously through the allocation stage which can result in blocks being allocated out-of-order. It would be nice to preserve as much of the logical order as possible.
In addition, the allocations are equally scattered across all top-level VDEVs but not all top-level VDEVs are created equally. The pipeline should be able to detect devices that are more capable of handling allocations and should allocate more blocks to those devices. This allows for dynamic allocation distribution when devices are imbalanced as fuller devices will tend to be slower than empty devices.
The change includes a new pool-wide allocation queue which would throttle and order allocations in the ZIO pipeline. The queue would be ordered by issued time and offset and would provide an initial amount of allocation of work to each top-level vdev. The allocation logic utilizes a reservation system to reserve allocations that will be performed by the allocator. Once an allocation is successfully completed it's scheduled on a given top-level vdev. Each top-level vdev maintains a maximum number of allocations that it can handle (mg_alloc_queue_depth). The pool-wide reserved allocations (top-levels * mg_alloc_queue_depth) are distributed across the top-level vdevs metaslab groups and round robin across all eligible metaslab groups to distribute the work. As top-levels complete their work, they receive additional work from the pool-wide allocation queue until the allocation queue is emptied.
Updated by Electric Monk almost 6 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
commit 0f7643c7376dd69a08acbfc9d1d7d548b10c846a Author: George Wilson <email@example.com> Date: 2016-08-02T16:44:16.000Z 7090 zfs should improve allocation order and throttle allocations Reviewed by: Adam Leventhal <firstname.lastname@example.org> Reviewed by: Alex Reece <email@example.com> Reviewed by: Christopher Siden <firstname.lastname@example.org> Reviewed by: Dan Kimmel <email@example.com> Reviewed by: Matthew Ahrens <firstname.lastname@example.org> Reviewed by: Paul Dagnelie <email@example.com> Reviewed by: Prakash Surya <firstname.lastname@example.org> Reviewed by: Sebastien Roy <email@example.com> Approved by: Robert Mustacchi <firstname.lastname@example.org>