Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?

Liste des GroupesRevenir à c arch 
Sujet : Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?
De : sfuld (at) *nospam* alumni.cmu.edu.invalid (Stephen Fuld)
Groupes : comp.arch
Date : 28. May 2025, 16:46:26
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <1017b4j$334ga$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11
User-Agent : Mozilla Thunderbird
On 5/28/2025 12:47 AM, Anton Ertl wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
On 5/27/2025 9:19 AM, Anton Ertl wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
On 5/27/2025 1:34 AM, Anton Ertl wrote:
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
On 5/26/2025 12:19 PM, John Levine wrote:
According to Stefan Monnier  <monnier@iro.umontreal.ca>:
Stephen Fuld [2025-05-26 11:16:25] wrote:
https://www.seagate.com/innovation/multi-actuator-hard-drives/
[...]
The fact that this is presented as two drives to the system makes me
suspect that the drive electronics is duplicated.
>
Not two drives, but two Logical Units (LUNS).
 <https://www.techopedia.com/definition/321/logical-unit-number-lun> says:
|The term LUN was initiated from the SCSI protocol and provided a
|methodology for identifying specific disc drives within a regular
|component such as a disc array.
 In the present context: If the drive electronics has the minimum
amount of duplication, why present the thing as two LUNs?
It allows there to be two commands outstanding (one per LUN) to be active at the same time without the added complexity of command queuing.   This allows overlapping the seeks and rotations of the two LUNs, thus improving performance.

 
It's not two separate
drives because there is only one host interface.
 In the scenario described above, disk arrays have only one host
interface but still contain separate drives, each drive identified by
a LUN.
Yes.

 
So, without knowing for sure, I think the disk has one set of host
interface electronics, one main CPU, one DRAM buffer, one motor control,
etc.  It says that it can transfer from both disks (presumably at least
one to/from the buffer) simultaneously, so it has two disk read channels
and two disk write channels.  But I don't think anything else is duplicated.
 In that case, why have two LUNs?  It seems to me that in this
scenario, it would be easier to use the drive as one 18TB LUN, no need
for the user to arrange the two LUNs into a RAID0 or JBOD.
But then, unless you used command queuing, you can't have seek overlap between the two "halfs" of the drive.

 In this
scenario the drive electronics could arrange the sectors of logically
consecutive tracks to come from alternating actuators, which allows to
double the sequential speed, and also to double the IOPS of random
accesses given enough concurrent requests.
You only get double the IOPS if the host supports command queuing.  As to whether to interleave the addresses, that is an independent question.   There are advantages and disadvantages, mainly revolving around (pun intended) how long the average user request is versus what is the unit of interleave.

My guess is that the eventual intent of Seagate was to provide that
scenario, but to get the project done quickly, they started out by
duplicating the drive electronics (only one motor controller is
connected, and (wild guess) spindown on idle is disabled; otherwise
they would need to synchronize that; or maybe they do, at least in
order to implement staggered spin-up); they added a front end that
provides a common host interface with the two LUNs (probably available
as off-the-shelf component), and the only new development necessary
for the project was the split actuator.  That's how it came out for
the 2X14 drive; and my guess is that the sales numbers were good
enough to respin it as 2X18 when the density per platter had increased
enough for that, but not good enough to perform the development of the
original plan.
Well, neither of us knows for sure.  But they already had eight platter drive hardware, so no new development for incorporating that, versus having to find some mechanism to anchor the "upper" drive motor to the casing that doesn't exist now.  And no need to add the "front end" you mention.  Plus if you were going to duplicate essentially all the electronics, (plus the added front end) you need space for the second circuit board, so you would probably have to sacrifice a platter to fit it within the form factor.  So it seems doubtful to me.  One other hint - no mention of separate caches for each actuator.  But again, I have no direct knowledge.
BTW, more information at
https://www.seagate.com/content/dam/seagate/migrated-assets/www-content/solutions/mach-2-multi-actuator-hard-drive/files/sc702.2-2101us-mach-2-faq.pdf
--
  - Stephen Fuld
(e-mail address disguised to prevent spam)

Date Sujet#  Auteur
27 May 25 * Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?19Stephen Fuld
27 May 25 `* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?18Anton Ertl
27 May 25  `* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?17Stephen Fuld
27 May 25   `* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?16Anton Ertl
28 May 25    `* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?15Stephen Fuld
28 May 25     `* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?14Anton Ertl
28 May 25      +* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?2Anton Ertl
28 May 25      i`- Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?1Stephen Fuld
28 May 25      +* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?10Stephen Fuld
28 May 25      i`* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?9Stefan Monnier
28 May 25      i `* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?8Stephen Fuld
28 May 25      i  `* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?7Stefan Monnier
28 May 25      i   `* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?6Stephen Fuld
28 May 25      i    `* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?5Stefan Monnier
28 May 25      i     `* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?4Stephen Fuld
28 May 25      i      +* Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?2MitchAlsup1
29 May 25      i      i`- Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?1Stephen Fuld
29 May 25      i      `- Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?1Stefan Monnier
29 May 25      `- Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It?1John Levine

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal