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

["Martin K. Petersen" <martin.petersen@oracle.com>]

Hi Damien!

> Single LUN multi-actuator hard-disks are cappable to seek and execute
> multiple commands in parallel. This capability is exposed to the host
> using the Concurrent Positioning Ranges VPD page (SCSI) and Log (ATA).
> Each positioning range describes the contiguous set of LBAs that an
> actuator serves.

I am not a big fan of the Concurrent Positioning Range terminology since
it is very specific to the implementation of multi-actuator disk drives.
With other types of media, "positioning" doesn't any sense. It is
unfortunate that CPR is the term that ended up in a spec that covers a
wide variety of devices and media types.

I also think that the "concurrent positioning" emphasizes the
performance aspect but not so much the fault domain which in many ways
is the more interesting part.

The purpose of exposing this information to the filesystems must be to
encourage them to use it. And therefore I think it is important that the
semantics and information conveyed is applicable outside of the
multi-actuator use case. It would be easy to expose this kind of
information for concatenated LVM devices, etc.

Anyway. I don't really have any objections to the series from an
implementation perspective. I do think "cpr" as you used in patch #2 is
a better name than "crange". But again, I wish we could come up with a
more accurate and less disk actuator centric terminology for the block
layer plumbing.

I would have voted for "fault_domain" but that ignores the performance
aspect. "independent_block_range", maybe? Why is naming always so hard?
:(

-- 
Martin K. Petersen	Oracle Linux Engineering