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
