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

[Hannes Reinecke <hare@suse.de>]

On 8/26/21 5:50 AM, Damien Le Moal wrote:
> On 2021/08/26 12:43, Martin K. Petersen wrote:
>>
>> Damien,
>>
>>> I am not super happy with the name either. I used this one as the
>>> least worst of possibilities I thought of.  seek_range/srange ? ->
>>> that is very HDD centric and as we can reuse this for things like
>>> dm-linear on top of SSDs, that does not really work.  I would prefer
>>> something that convey the idea of "parallel command execution", since
>>> this is the main point of the interface. prange ? cdm_range ?
>>> req_range ?
>>
>> How about independent_access_range? That doesn't imply head positioning
>> and can also be used to describe a fault domain. And it is less
>> disk-centric than concurrent_positioning_range.
> 
> I like it, but a bit long-ish. Do you think shortening to access_range would be
> acceptable ?
> 
> we would have:
> 
> /sys/block/XYZ/queue/access_ranges/...
> 
> and
> 
> struct blk_access_range {
> 	...
> 	sector_t sector;
> 	sector_t nr_sectors;
> }
> 
> struct blk_access_range *arange;
> 
> Adding independent does make everything even more obvious, but names become
> rather long. Not an issue for the sysfs directory I think, but
> 
> struct blk_independent_access_range {
> 	...
> 	sector_t sector;
> 	sector_t nr_sectors;
> }
> 
> is rather a long struct name. Shortening independent to "ind" could very easily
> be confused with "indirection", so that is not an option. And "iaccess" is
> obscure...
> 
I'd vote for access_range.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer