Re: [PATCH v5 0/5] Initial support for multi-actuator HDDs

[Damien Le Moal <Damien.LeMoal@wdc.com>]

On 2021/08/18 11:24, Martin K. Petersen wrote:
> 
> Damien,
> 
>> With the single LUN approach, the fault domain does not really change
>> from a regular device. The typical use in case of bad heads would be
>> to replace the drive or reformat it at lower capacity with head
>> depop. That could be avoided with dm-linear on top (one DM per
>> actuator) though.
> 
> I was more thinking along the lines of btrfs making sure to place
> dup metadata on different actuators or similar.
> 
>> The above point led me to this informational only implementation.
>> Without optimization, we get the same as today. No changes in
>> performance and use.  Better IOPS is gain for lucky workloads
>> (typically random ones). Going forward, more reliable IOPS &
>> throughput gains are possible with some additional changes.
> 
> Sure, but that means the ranges need to affect both I/O scheduling and
> data placement. We need to make sure that the data placement interface
> semantics are applicable to other types of media than multi actuator
> drives. Filesystems shouldn't have to look at different queue limits if
> they sit on top of dm-linear instead of sd. From an I/O scheduling
> perspective I concur that device implementation details are pertinent.

Currently, FSes cannot know the dm-linear config. The queue crange interface can
actually unify this for split/dual actuator and dm-linear like logical disks.

I need to send patches to dm-devel for that though as currently, dm-linear does
not expose its config as cranges. If I recall correctly, Hannes was also
interested in playing with that too :)


-- 
Damien Le Moal
Western Digital Research