archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <>
To: "" <>,
	Tim Walker <>
Cc: Phillip Susi <>, Jens Axboe <>,
	"" <>,
	"Martin K . Petersen" <>,
	"" <>
Subject: Re: [PATCH v6 0/5] Initial support for multi-actuator HDDs
Date: Sun, 29 Aug 2021 22:55:59 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: YSkVwSfQ/

On 2021/08/28 1:43, Christoph Hellwig wrote:
> On Fri, Aug 27, 2021 at 02:28:58PM +0000, Tim Walker wrote:
>> There is nothing in the spec that requires the ranges to be contiguous
>> or non-overlapping.
> Yikes, that is a pretty stupid standard.  Almost as bad as allowing
> non-uniform sized non-power of two sized zones :)
>> It's easy to imagine a HDD architecture that allows multiple heads to access the same sectors on the disk. It's also easy to imagine a workload scenario where parallel access to the same disk could be useful. (Think of a typical storage design that sequentially writes new user data gradually filling the disk, while simultaneously supporting random user reads over the written data.)
> But for those drivers you do not actually need this scheme at all.


> Storage devices that support higher concurrency are bog standard with
> SSDs and if you want to go back storage arrays.  The only interesting
> case is when these ranges are separate so that the access can be carved
> up based on the boundary.  Now I don't want to give people ideas with
> overlapping but not identical, which would be just horrible.

Agree too. And looking at my patch again, the function disk_check_iaranges() in
patch 1 only checks that the overall sector range of all access ranges is form 0
to capacity - 1, but it does not check for holes nor overlap. I need to change
that and ignore any disk that reports overlapping ranges or ranges with holes in
the LBA space. Holes would be horrible and if we have overlap, then the drive
can optimize by itself. Will resend a V7 with corrections for that.

Damien Le Moal
Western Digital Research

  parent reply	other threads:[~2021-08-29 22:56 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-27  7:50 [PATCH v6 0/5] Initial support for multi-actuator HDDs Damien Le Moal
2021-08-27  7:50 ` [PATCH v6 1/5] block: Add independent access ranges support Damien Le Moal
2021-08-27  7:50 ` [PATCH v6 2/5] scsi: sd: add concurrent positioning " Damien Le Moal
2021-08-27  7:50 ` [PATCH v6 3/5] libata: support concurrent positioning ranges log Damien Le Moal
2021-08-27  7:50 ` [PATCH v6 4/5] doc: document sysfs queue/independent_access_ranges attributes Damien Le Moal
2021-08-27  7:50 ` [PATCH v6 5/5] doc: Fix typo in request queue sysfs documentation Damien Le Moal
2021-08-27 13:58 ` [PATCH v6 0/5] Initial support for multi-actuator HDDs Phillip Susi
2021-08-27 14:28   ` Tim Walker
2021-08-27 16:41     ` Christoph Hellwig
2021-08-27 17:00       ` Tim Walker
2021-08-29 22:55       ` Damien Le Moal [this message]
2021-08-27 17:34     ` Phillip Susi
2021-08-29 22:50       ` Damien Le Moal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).