Linux-Block Archive on lore.kernel.org
 help / color / Atom feed
* [LSF/MM/BPF TOPIC] Multi-actuator HDDs
@ 2020-02-10 18:01 Muhammad Ahmad
  2020-02-10 18:26 ` Keith Busch
  2020-02-10 21:52 ` Dave Chinner
  0 siblings, 2 replies; 5+ messages in thread
From: Muhammad Ahmad @ 2020-02-10 18:01 UTC (permalink / raw)
  To: linux-fsdevel, linux-block, linux-scsi; +Cc: Tim Walker

Background:
As the capacity of HDDs increases so is the need to increase
performance to efficiently utilize this increase in capacity. The
current school of thought is to use Multi-Actuators to increase
spinning disk performance. Seagate has already announced it’s SAS
Dual-Lun, Dual-Actuator device. [1]

Discussion Proposal:
What impacts multi-actuator HDDs has on the linux storage stack?

A discussion on the pros & cons of accessing the actuators through a
single combined LUN or multiple individual LUNs? In the single LUN
scenario, how should the device communicate it’s LBA to actuator
mapping? In the case of multi-lun, how should we manage commands that
affect both actuators?

For NVMe HDDs are namespaces the appropriate abstraction of the
multiple actuators?

We would like to share our work mapping LUNs/Actuators through LVM &
MD-RAID to study the performance characteristics and hope to get some
feedback from the community on this approach.

[1] https://www.seagate.com/solutions/mach-2-multi-actuator-hard-drive/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LSF/MM/BPF TOPIC] Multi-actuator HDDs
  2020-02-10 18:01 [LSF/MM/BPF TOPIC] Multi-actuator HDDs Muhammad Ahmad
@ 2020-02-10 18:26 ` Keith Busch
  2020-02-11 19:18   ` James Bottomley
  2020-02-10 21:52 ` Dave Chinner
  1 sibling, 1 reply; 5+ messages in thread
From: Keith Busch @ 2020-02-10 18:26 UTC (permalink / raw)
  To: Muhammad Ahmad; +Cc: linux-fsdevel, linux-block, linux-scsi, Tim Walker

On Mon, Feb 10, 2020 at 12:01:13PM -0600, Muhammad Ahmad wrote:
> For NVMe HDDs are namespaces the appropriate abstraction of the
> multiple actuators?

This sounds closer to what "NVM Sets" defines rather than namespaces.
Section 4.9 from NVMe 1.4 spec has additional details if interested.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LSF/MM/BPF TOPIC] Multi-actuator HDDs
  2020-02-10 18:01 [LSF/MM/BPF TOPIC] Multi-actuator HDDs Muhammad Ahmad
  2020-02-10 18:26 ` Keith Busch
@ 2020-02-10 21:52 ` Dave Chinner
  2020-02-11 19:23   ` Tim Walker
  1 sibling, 1 reply; 5+ messages in thread
From: Dave Chinner @ 2020-02-10 21:52 UTC (permalink / raw)
  To: Muhammad Ahmad; +Cc: linux-fsdevel, linux-block, linux-scsi, Tim Walker

On Mon, Feb 10, 2020 at 12:01:13PM -0600, Muhammad Ahmad wrote:
> Background:
> As the capacity of HDDs increases so is the need to increase
> performance to efficiently utilize this increase in capacity. The
> current school of thought is to use Multi-Actuators to increase
> spinning disk performance. Seagate has already announced it’s SAS
> Dual-Lun, Dual-Actuator device. [1]
> 
> Discussion Proposal:
> What impacts multi-actuator HDDs has on the linux storage stack?
> 
> A discussion on the pros & cons of accessing the actuators through a
> single combined LUN or multiple individual LUNs? In the single LUN
> scenario, how should the device communicate it’s LBA to actuator
> mapping? In the case of multi-lun, how should we manage commands that
> affect both actuators?

What ground does this cover that wasn't discussed a couple of years
ago at LSFMM?

https://lwn.net/Articles/753652/

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LSF/MM/BPF TOPIC] Multi-actuator HDDs
  2020-02-10 18:26 ` Keith Busch
@ 2020-02-11 19:18   ` James Bottomley
  0 siblings, 0 replies; 5+ messages in thread
From: James Bottomley @ 2020-02-11 19:18 UTC (permalink / raw)
  To: Keith Busch, Muhammad Ahmad
  Cc: linux-fsdevel, linux-block, linux-scsi, Tim Walker

On Mon, 2020-02-10 at 10:26 -0800, Keith Busch wrote:
> On Mon, Feb 10, 2020 at 12:01:13PM -0600, Muhammad Ahmad wrote:
> > For NVMe HDDs are namespaces the appropriate abstraction of the
> > multiple actuators?
> 
> This sounds closer to what "NVM Sets" defines rather than namespaces.
> Section 4.9 from NVMe 1.4 spec has additional details if interested.

I've got to say that since multi-actuator devices will always be
spinning rust, bending NVMe concepts to fit them seems horribly wrong
... as does adding any rotational devices to NVMe: You just built a
clean NVM stack ... let's not contaminate it.

James


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [LSF/MM/BPF TOPIC] Multi-actuator HDDs
  2020-02-10 21:52 ` Dave Chinner
@ 2020-02-11 19:23   ` Tim Walker
  0 siblings, 0 replies; 5+ messages in thread
From: Tim Walker @ 2020-02-11 19:23 UTC (permalink / raw)
  To: Dave Chinner; +Cc: Muhammad Ahmad, linux-fsdevel, linux-block, linux-scsi

On Mon, Feb 10, 2020 at 4:52 PM Dave Chinner <david@fromorbit.com> wrote:
>
> On Mon, Feb 10, 2020 at 12:01:13PM -0600, Muhammad Ahmad wrote:
> > Background:
> > As the capacity of HDDs increases so is the need to increase
> > performance to efficiently utilize this increase in capacity. The
> > current school of thought is to use Multi-Actuators to increase
> > spinning disk performance. Seagate has already announced it’s SAS
> > Dual-Lun, Dual-Actuator device. [1]
> >
> > Discussion Proposal:
> > What impacts multi-actuator HDDs has on the linux storage stack?
> >
> > A discussion on the pros & cons of accessing the actuators through a
> > single combined LUN or multiple individual LUNs? In the single LUN
> > scenario, how should the device communicate it’s LBA to actuator
> > mapping? In the case of multi-lun, how should we manage commands that
> > affect both actuators?
>
> What ground does this cover that wasn't discussed a couple of years
> ago at LSFMM?
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_753652_&d=DwIDaQ&c=IGDlg0lD0b-nebmJJ0Kp8A&r=NW1X0yRHNNEluZ8sOGXBxCbQJZPWcIkPT0Uy3ynVsFU&m=2Eb6xxsYMqNOn4F3Yiola3ef2BTCKKg06zpnqJ_m1c8&s=JtxAw3Y13PHlYJygS847dBUVRXeM061Snm3hq01DFlY&e=
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com

Hi all-

The multi-actuator fundamentals remain the same from a couple of years
ago. One development is to combine the actuators' address spaces into
a single LUN. We'd like to show you a couple of system block diagrams,
and talk about the queue management and command scheduling.

Best regards,
-Tim

-- 
Tim Walker
Product Design Systems Engineering, Seagate Technology
(303) 775-3770

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-10 18:01 [LSF/MM/BPF TOPIC] Multi-actuator HDDs Muhammad Ahmad
2020-02-10 18:26 ` Keith Busch
2020-02-11 19:18   ` James Bottomley
2020-02-10 21:52 ` Dave Chinner
2020-02-11 19:23   ` Tim Walker

Linux-Block Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-block/0 linux-block/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-block linux-block/ https://lore.kernel.org/linux-block \
		linux-block@vger.kernel.org
	public-inbox-index linux-block

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-block


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git