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.
--
Martin K. Petersen Oracle Linux Engineering
On 2021/08/18 11:24, Martin K. Petersen wrote:
Damien,
quoted
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.
quoted
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