linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Tim Walker <tim.t.walker@seagate.com>
Cc: Phillip Susi <phill@thesusis.net>,
	Damien Le Moal <damien.lemoal@wdc.com>,
	Jens Axboe <axboe@kernel.dk>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH v6 0/5] Initial support for multi-actuator HDDs
Date: Fri, 27 Aug 2021 17:41:37 +0100	[thread overview]
Message-ID: <YSkVwSfQ/9RCKfEG@infradead.org> (raw)
In-Reply-To: <63D90989-AFAF-410B-AD11-EDF71CEEE666@seagate.com>

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.

  reply	other threads:[~2021-08-27 16:43 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 [this message]
2021-08-27 17:00       ` Tim Walker
2021-08-29 22:55       ` Damien Le Moal
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=YSkVwSfQ/9RCKfEG@infradead.org \
    --to=hch@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=damien.lemoal@wdc.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=phill@thesusis.net \
    --cc=tim.t.walker@seagate.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).