From: Tim Walker <tim.t.walker@seagate.com>
To: Phillip Susi <phill@thesusis.net>,
Damien Le Moal <damien.lemoal@wdc.com>
Cc: 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 14:28:58 +0000 [thread overview]
Message-ID: <63D90989-AFAF-410B-AD11-EDF71CEEE666@seagate.com> (raw)
In-Reply-To: <874kbbugtw.fsf@vps.thesusis.net>
On Friday, August 27, 2021 at 10:10:15 AM Phillip Susi wrote:
>
>This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.
>
>
>Damien Le Moal <damien.lemoal@wdc.com> writes:
>
>> 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.
>
>Are these ranges exlusive to each actuator or can they overlap?
>
>> This series does not attempt in any way to optimize accesses to
>> multi-actuator devices (e.g. block IO schedulers or filesystems). This
>> initial support only exposes the independent access ranges information
>> to user space through sysfs.
>
>Is the plan to eventually change the IO scheduler to maintain two
>different queues, one for each actuator, and send down commands for two
>different IO streams that the elevator attempts to keep sequential?
>
>
There is nothing in the spec that requires the ranges to be contiguous or non-overlapping. 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.)
The IO Scheduler is a useful place to implement per-actuator load management, but with the LBA-to-actuator mapping available to user space (via sysfs) it could also be done at the user level. Or pretty much anywhere else where we have knowledge and control of the various streams.
The system is flexible and adaptable to a really wide range of HDD designs and usage models.
Best regards,
-Tim
Tim Walker
Seagate Research
next prev parent reply other threads:[~2021-08-27 14:36 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 [this message]
2021-08-27 16:41 ` Christoph Hellwig
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=63D90989-AFAF-410B-AD11-EDF71CEEE666@seagate.com \
--to=tim.t.walker@seagate.com \
--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 \
/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).