• Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You

    From John Levine@21:1/5 to All on Mon May 26 17:42:29 2025
    According to Chris M. Thomasson <[email protected]>:
    For some damn reason I thought of a fractal disk arm, an arm that had a >fractal structure, the disk rotates, but the fractal arm can read from
    many places at once? Try not to flame me too much. ;^)

    Dunno about fractal, but I have used head per track disks with a fixed arm
    with many heads, and a disk with a crooked Y-shaped arm with two heads over
    two tracks. None of them could do more than one transfer at a time but I
    think that was a limit of the electronics of the era, not a fundamental
    issue.


    --
    Regards,
    John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
    Please consider the environment before reading this e-mail. https://jl.ly

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Fuld@21:1/5 to John Levine on Mon May 26 11:16:25 2025
    On 5/26/2025 10:42 AM, John Levine wrote:
    According to Chris M. Thomasson <[email protected]>:
    For some damn reason I thought of a fractal disk arm, an arm that had a
    fractal structure, the disk rotates, but the fractal arm can read from
    many places at once? Try not to flame me too much. ;^)

    Dunno about fractal, but I have used head per track disks with a fixed arm with many heads, and a disk with a crooked Y-shaped arm with two heads over two tracks.

    Yup. And IIRC the IBM 3380 had a linear actuator with two heads per
    arm, one covering the outer cylinders, the other the inner cylinders.
    The tradeoff was shorter seeks, thus smaller seek time but higher cost
    due to more heads.


    None of them could do more than one transfer at a time but I
    think that was a limit of the electronics of the era, not a fundamental issue.

    Depends on what you mean by more than one transfer at a time. If you
    mean two simultaneous independent data streams to the host, that would
    require a second host connection. But if you mean two simultaneous
    transfers into a buffer in order to get higher host transfer rate, that
    is apparently now available.

    https://www.seagate.com/innovation/multi-actuator-hard-drives/

    However, I think that, except for streaming applications, the bigger
    payoff is two simultaneous seeks.



    --
    - Stephen Fuld
    (e-mail address disguised to prevent spam)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Monnier@21:1/5 to All on Mon May 26 14:58:57 2025
    Stephen Fuld [2025-05-26 11:16:25] wrote:
    https://www.seagate.com/innovation/multi-actuator-hard-drives/

    Hmmm, hard to believe it makes commercial sense: if you need higher performance, when would this be price-competitive with an SSD?

    Also, that page is very light on details, but the image they include
    suggests the two actuators are used on separate platters, so it's akin
    to cramming a 2-disk-RAID0 into a single HDD enclosure.

    Maybe part of the gain of having two actuators is that each actuator is
    a bit lighter?


    Stefan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Levine@21:1/5 to All on Mon May 26 19:19:55 2025
    According to Stefan Monnier <[email protected]>:
    Stephen Fuld [2025-05-26 11:16:25] wrote:
    https://www.seagate.com/innovation/multi-actuator-hard-drives/

    Hmmm, hard to believe it makes commercial sense: if you need higher >performance, when would this be price-competitive with an SSD?

    Also, that page is very light on details, but the image they include
    suggests the two actuators are used on separate platters, so it's akin
    to cramming a 2-disk-RAID0 into a single HDD enclosure.

    The data sheet says it is in effect two 7TB disks in a single enclosure.

    It seems to have come and gone. Nobody has them new, refurbished are
    $150 - $200 on eBay. An SSD of similar size is in the $2000 range so
    it would have made sense for a data warehouse.



    --
    Regards,
    John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
    Please consider the environment before reading this e-mail. https://jl.ly

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to Stephen Fuld on Mon May 26 20:31:49 2025
    Stephen Fuld <[email protected]d> writes:
    On 5/26/2025 10:42 AM, John Levine wrote:
    According to Chris M. Thomasson <[email protected]>:
    For some damn reason I thought of a fractal disk arm, an arm that had a
    fractal structure, the disk rotates, but the fractal arm can read from
    many places at once? Try not to flame me too much. ;^)

    Dunno about fractal, but I have used head per track disks with a fixed arm >> with many heads, and a disk with a crooked Y-shaped arm with two heads over >> two tracks.

    Yup. And IIRC the IBM 3380 had a linear actuator with two heads per
    arm, one covering the outer cylinders, the other the inner cylinders.
    The tradeoff was shorter seeks, thus smaller seek time but higher cost
    due to more heads.

    Burroughs had some memorex-built drives that had multiple actuators which allowed it to sustain two simultaneous independent transfers from the
    media. This was circa 1988. The drives were often shared between two
    to four systems in loosely coupled multiprocessor configurations.

    Required a forklift to deliver to the machine room. 1GB capacity.

    But if you mean two simultaneous
    transfers into a buffer in order to get higher host transfer rate, that
    is apparently now available.

    https://www.seagate.com/innovation/multi-actuator-hard-drives/

    Ah, what's old is new again....

    I can't imagine why Seagate calls that "The world's first multiactuator technology",
    given we had it four decades ago.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Fuld@21:1/5 to Stefan Monnier on Mon May 26 13:36:30 2025
    On 5/26/2025 11:58 AM, Stefan Monnier wrote:
    Stephen Fuld [2025-05-26 11:16:25] wrote:
    https://www.seagate.com/innovation/multi-actuator-hard-drives/

    Hmmm, hard to believe it makes commercial sense: if you need higher performance, when would this be price-competitive with an SSD?

    It should be not much more costly than a single disk of the same
    capacity. It has the same number of heads, platters, and of course the
    same enclosure, etc. A little more work to separate the two arm
    magnetic actuators. The same electronics, except for, and this is
    probably the most expensive part, an additional read channel. So still
    a lot cheaper than an SSD.


    Also, that page is very light on details, but the image they include
    suggests the two actuators are used on separate platters, so it's akin
    to cramming a 2-disk-RAID0 into a single HDD enclosure.

    Yeah, sort of. But a single drive motor, a single host interface, microprocessor, etc. So quite a bit less costly than two separate disks.


    Maybe part of the gain of having two actuators is that each actuator is
    a bit lighter?

    I suspect that is insignificant.


    --
    - Stephen Fuld
    (e-mail address disguised to prevent spam)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Fuld@21:1/5 to Scott Lurndal on Mon May 26 13:45:00 2025
    On 5/26/2025 1:31 PM, Scott Lurndal wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/26/2025 10:42 AM, John Levine wrote:
    According to Chris M. Thomasson <[email protected]>:
    For some damn reason I thought of a fractal disk arm, an arm that had a >>>> fractal structure, the disk rotates, but the fractal arm can read from >>>> many places at once? Try not to flame me too much. ;^)

    Dunno about fractal, but I have used head per track disks with a fixed arm >>> with many heads, and a disk with a crooked Y-shaped arm with two heads over >>> two tracks.

    Yup. And IIRC the IBM 3380 had a linear actuator with two heads per
    arm, one covering the outer cylinders, the other the inner cylinders.
    The tradeoff was shorter seeks, thus smaller seek time but higher cost
    due to more heads.

    Burroughs had some memorex-built drives that had multiple actuators which allowed it to sustain two simultaneous independent transfers from the
    media.

    Interesting. I presume that the two transfers had to be to two
    different head of string/controllers.


    This was circa 1988. The drives were often shared between two
    to four systems in loosely coupled multiprocessor configurations.

    That makes sense. No need to mess with the OS to allow two transfers
    to/from the same drive.


    Ah, what's old is new again....

    I can't imagine why Seagate calls that "The world's first multiactuator technology",
    given we had it four decades ago.

    Come on, Scott! Both of us old codgers learned long ago to separate
    Marketing from reality! :-) I'll bet 1988 was before many of Seagate's
    people were born, much less involved in the industry.


    --
    - Stephen Fuld
    (e-mail address disguised to prevent spam)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to Stephen Fuld on Mon May 26 23:24:50 2025
    Stephen Fuld <[email protected]d> writes:
    On 5/26/2025 1:31 PM, Scott Lurndal wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/26/2025 10:42 AM, John Levine wrote:
    According to Chris M. Thomasson <[email protected]>:
    For some damn reason I thought of a fractal disk arm, an arm that had a >>>>> fractal structure, the disk rotates, but the fractal arm can read from >>>>> many places at once? Try not to flame me too much. ;^)

    Dunno about fractal, but I have used head per track disks with a fixed arm >>>> with many heads, and a disk with a crooked Y-shaped arm with two heads over
    two tracks.

    Yup. And IIRC the IBM 3380 had a linear actuator with two heads per
    arm, one covering the outer cylinders, the other the inner cylinders.
    The tradeoff was shorter seeks, thus smaller seek time but higher cost
    due to more heads.

    Burroughs had some memorex-built drives that had multiple actuators which
    allowed it to sustain two simultaneous independent transfers from the
    media.

    Interesting. I presume that the two transfers had to be to two
    different head of string/controllers.

    Each actuator appeared to the disk controller as a disk unit,
    so both could be transfering data simultaneously to one or more
    hosts. A single controller could control up to 16 units;
    a box called an 'exchange' could sit upstream of a controller
    and allow the controller to be accessed by multiple host channels
    (up to 16 host channels connected to eight exchange boxes servicing
    multiple disk controllers to which the drive units were connected).

    Those cables were all 1.25-1.50" in diameter and could really
    crowd the subfloor spaces.


    This was circa 1988. The drives were often shared between two
    to four systems in loosely coupled multiprocessor configurations.

    That makes sense. No need to mess with the OS to allow two transfers
    to/from the same drive.

    The hosts were connected to a separate I/O device called a shared systems processor
    which basically supported block-level locking between the loosely coupled hosts. Before accessing a shared file block, a block lock on the unit needed to be acquired by the host by communicating with the SSP.



    Ah, what's old is new again....

    I can't imagine why Seagate calls that "The world's first multiactuator technology",
    given we had it four decades ago.

    Come on, Scott! Both of us old codgers learned long ago to separate >Marketing from reality! :-) I'll bet 1988 was before many of Seagate's >people were born, much less involved in the industry.

    :-)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to Stephen Fuld on Mon May 26 23:26:54 2025
    Stephen Fuld <[email protected]d> writes:
    On 5/26/2025 11:58 AM, Stefan Monnier wrote:
    Stephen Fuld [2025-05-26 11:16:25] wrote:
    https://www.seagate.com/innovation/multi-actuator-hard-drives/

    Hmmm, hard to believe it makes commercial sense: if you need higher
    performance, when would this be price-competitive with an SSD?

    It should be not much more costly than a single disk of the same
    capacity. It has the same number of heads, platters, and of course the
    same enclosure, etc. A little more work to separate the two arm
    magnetic actuators. The same electronics, except for, and this is
    probably the most expensive part, an additional read channel. So still
    a lot cheaper than an SSD.

    Burroughs systems did have SSD's (DRAM-based) which were used for
    the MCP disk (which held the run/spo/maintenance logs) which had
    frequent accesses from the late 70's. They weren't cheap.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Fuld@21:1/5 to John Levine on Mon May 26 21:52:45 2025
    On 5/26/2025 12:19 PM, John Levine wrote:
    According to Stefan Monnier <[email protected]>:
    Stephen Fuld [2025-05-26 11:16:25] wrote:
    https://www.seagate.com/innovation/multi-actuator-hard-drives/

    Hmmm, hard to believe it makes commercial sense: if you need higher
    performance, when would this be price-competitive with an SSD?

    Also, that page is very light on details, but the image they include
    suggests the two actuators are used on separate platters, so it's akin
    to cramming a 2-disk-RAID0 into a single HDD enclosure.

    The data sheet says it is in effect two 7TB disks in a single enclosure.

    It seems to have come and gone. Nobody has them new, refurbished are
    $150 - $200 on eBay. An SSD of similar size is in the $2000 range so
    it would have made sense for a data warehouse.

    I thought it would. I believe you about its current state, but I wonder
    why it wasn't more successful. It seems like a big improvement in
    throughput for very little extra cost.



    --
    - Stephen Fuld
    (e-mail address disguised to prevent spam)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Stephen Fuld on Tue May 27 08:34:08 2025
    Stephen Fuld <[email protected]d> writes:
    On 5/26/2025 12:19 PM, John Levine wrote:
    According to Stefan Monnier <[email protected]>:
    Stephen Fuld [2025-05-26 11:16:25] wrote:
    https://www.seagate.com/innovation/multi-actuator-hard-drives/
    [...]
    I believe you about its current state, but I wonder
    why it wasn't more successful. It seems like a big improvement in
    throughput for very little extra cost.

    It seems that the technology is still on offer, e.g.

    https://geizhals.eu/seagate-exos-x-2x18-18tb-st18000nm0272-a2883003.html

    As for the price (and ignoring offers that are not in stock, or where
    the offers vary wildly vary):

    EUR Drive
    427 Seagate Exos X - 2X18 18TB (2x9TB)
    350 Exos X X18 18TB
    440 2xToshiba N300 NAS Systems 10TB (total 20TB)
    330 2xSeagate Exos E - 7E10 8TB (total 16TB)
    385 10TB HDD + 8TB HDD (total 18TB)

    So you pay almost as much as for 2 10TB drives, but get only 2 9TB
    drives in one enclosure. The power consumption may be better for the
    2X18 drive, though.

    - anton
    --
    'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
    Mitch Alsup, <[email protected]>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Fuld@21:1/5 to Anton Ertl on Tue May 27 07:34:43 2025
    On 5/27/2025 1:34 AM, Anton Ertl wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/26/2025 12:19 PM, John Levine wrote:
    According to Stefan Monnier <[email protected]>:
    Stephen Fuld [2025-05-26 11:16:25] wrote:
    https://www.seagate.com/innovation/multi-actuator-hard-drives/
    [...]
    I believe you about its current state, but I wonder
    why it wasn't more successful. It seems like a big improvement in
    throughput for very little extra cost.

    It seems that the technology is still on offer, e.g.

    https://geizhals.eu/seagate-exos-x-2x18-18tb-st18000nm0272-a2883003.html

    As for the price (and ignoring offers that are not in stock, or where
    the offers vary wildly vary):

    EUR Drive
    427 Seagate Exos X - 2X18 18TB (2x9TB)
    350 Exos X X18 18TB
    440 2xToshiba N300 NAS Systems 10TB (total 20TB)
    330 2xSeagate Exos E - 7E10 8TB (total 16TB)
    385 10TB HDD + 8TB HDD (total 18TB)

    So you pay almost as much as for 2 10TB drives, but get only 2 9TB
    drives in one enclosure. The power consumption may be better for the
    2X18 drive, though.

    Thanks Anton. So cost per GB is close, but the single drive is still
    more expensive. :-( It should draw less power and require less cooling;
    one drive motor versus two, and except for the read channel, half the electronics. Slightly worse performance, as only one host transfer simultaneously.

    Overall, not a terrible deal, but not a great bargain. I'll bet the
    vendor gets better margins on it. Interesting!


    --
    - Stephen Fuld
    (e-mail address disguised to prevent spam)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Stephen Fuld on Tue May 27 16:19:54 2025
    Stephen Fuld <[email protected]d> writes:
    On 5/27/2025 1:34 AM, Anton Ertl wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/26/2025 12:19 PM, John Levine wrote:
    According to Stefan Monnier <[email protected]>:
    Stephen Fuld [2025-05-26 11:16:25] wrote:
    https://www.seagate.com/innovation/multi-actuator-hard-drives/
    [...]
    It should draw less power and require less cooling;
    one drive motor versus two

    Probably not for that reason, but because with two drives there are 4
    case housing walls parallel to rotating platters (resulting in more friction) rather than 2 walls for the 2x18 drive.

    and except for the read channel, half the
    electronics.

    The fact that this is presented as two drives to the system makes me
    suspect that the drive electronics is duplicated.

    - anton
    --
    'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
    Mitch Alsup, <[email protected]>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Fuld@21:1/5 to Anton Ertl on Tue May 27 20:57:34 2025
    On 5/27/2025 9:19 AM, Anton Ertl wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/27/2025 1:34 AM, Anton Ertl wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/26/2025 12:19 PM, John Levine wrote:
    According to Stefan Monnier <[email protected]>:
    Stephen Fuld [2025-05-26 11:16:25] wrote:
    https://www.seagate.com/innovation/multi-actuator-hard-drives/
    [...]
    It should draw less power and require less cooling;
    one drive motor versus two

    Probably not for that reason, but because with two drives there are 4
    case housing walls parallel to rotating platters (resulting in more friction) rather than 2 walls for the 2x18 drive.

    and except for the read channel, half the
    electronics.

    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). It's not two separate
    drives because there is only one host interface. The two LUNS are like
    an old mainframe system where you might have a single controller with
    multiple drives behind it. Note the interface is SAS, which is derived
    from the old parallel SCSI, which supported LUNS. I may be wrong about
    this, but I don't believe SATA supports LUNS, but even if it does, that
    is still not two separate physical units.

    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.


    --
    - Stephen Fuld
    (e-mail address disguised to prevent spam)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Stephen Fuld on Wed May 28 07:47:41 2025
    Stephen Fuld <[email protected]d> writes:
    On 5/27/2025 9:19 AM, Anton Ertl wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/27/2025 1:34 AM, Anton Ertl wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/26/2025 12:19 PM, John Levine wrote:
    According to Stefan Monnier <[email protected]>:
    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'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.

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

    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.

    While the minimal-duplication approach would be cheaper if enough
    units are sold, my guess is that the number of 2X drives sold is not
    high enough for that, and so it's cheaper to use two mass-produced
    drive electronics and one mass-produced LUN-splitter instead.

    The fact that the idle power consumption of the 2X14 (7W) is higher
    than the idle power consumption of the X14 (5W) (<https://www.storagereview.com/news/seagate-exos-2x14-hdd-delivers-524mb-s>
    is another hint that there probably is more rather than less
    duplication.

    - anton
    --
    'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
    Mitch Alsup, <[email protected]>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Ertl@21:1/5 to Anton Ertl on Wed May 28 14:50:35 2025
    [email protected] (Anton Ertl) writes:
    Stephen Fuld <[email protected]d> writes:
    On 5/27/2025 9:19 AM, Anton Ertl wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/27/2025 1:34 AM, Anton Ertl wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/26/2025 12:19 PM, John Levine wrote:
    According to Stefan Monnier <[email protected]>:
    Stephen Fuld [2025-05-26 11:16:25] wrote:
    https://www.seagate.com/innovation/multi-actuator-hard-drives/
    [...]
    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.

    While the minimal-duplication approach would be cheaper if enough
    units are sold, my guess is that the number of 2X drives sold is not
    high enough for that, and so it's cheaper to use two mass-produced
    drive electronics and one mass-produced LUN-splitter instead.

    The fact that the idle power consumption of the 2X14 (7W) is higher
    than the idle power consumption of the X14 (5W) >(<https://www.storagereview.com/news/seagate-exos-2x14-hdd-delivers-524mb-s> >is another hint that there probably is more rather than less
    duplication.

    Counterevidence for my theory: The Exos X drives are all listed as
    having 256MB of cache, including the 2X drives. If the electronics
    were fully duplicated, they could list 512MB.

    - anton
    --
    'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
    Mitch Alsup, <[email protected]>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Fuld@21:1/5 to Anton Ertl on Wed May 28 08:46:26 2025
    On 5/28/2025 12:47 AM, Anton Ertl wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/27/2025 9:19 AM, Anton Ertl wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/27/2025 1:34 AM, Anton Ertl wrote:
    Stephen Fuld <[email protected]d> writes:
    On 5/26/2025 12:19 PM, John Levine wrote:
    According to Stefan Monnier <[email protected]>:
    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)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Fuld@21:1/5 to Anton Ertl on Wed May 28 08:48:13 2025
    On 5/28/2025 7:50 AM, Anton Ertl wrote:

    snip

    Counterevidence for my theory: The Exos X drives are all listed as
    having 256MB of cache, including the 2X drives. If the electronics
    were fully duplicated, they could list 512MB.

    Our posts mentioning this "crossed in the mail" :-)



    --
    - Stephen Fuld
    (e-mail address disguised to prevent spam)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Monnier@21:1/5 to All on Wed May 28 12:08:35 2025
    Stephen Fuld [2025-05-28 08:46:26] wrote:
    You only get double the IOPS if the host supports command queuing.

    I'd expect that command queuing is the only case that really matters in practice.

    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.

    That seems like a more important benefit: the users get to choose how to
    spread their data depending on their specific use case.


    Stefan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Fuld@21:1/5 to Stefan Monnier on Wed May 28 09:20:27 2025
    On 5/28/2025 9:08 AM, Stefan Monnier wrote:
    Stephen Fuld [2025-05-28 08:46:26] wrote:
    You only get double the IOPS if the host supports command queuing.

    I'd expect that command queuing is the only case that really matters in practice.

    You may be right. And I expect most applications will use that. But
    the cost of presenting as two LUNs is essentially zero, why not support
    it for those "legacy" systems not supporting 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.

    That seems like a more important benefit: the users get to choose how to spread their data depending on their specific use case.

    I don't disagree, though I didn't see any mechanism for the user to
    specify the unit of interleave. Of course you could do this in the host
    file system.


    --
    - Stephen Fuld
    (e-mail address disguised to prevent spam)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Monnier@21:1/5 to All on Wed May 28 12:32:07 2025
    John Levine [2025-05-26 19:19:55] wrote:
    According to Stefan Monnier <[email protected]>:
    Hmmm, hard to believe it makes commercial sense: if you need higher >>performance, when would this be price-competitive with an SSD?
    [...]
    It seems to have come and gone. Nobody has them new, refurbished are
    $150 - $200 on eBay. An SSD of similar size is in the $2000 range so
    it would have made sense for a data warehouse.

    The prices I see currently are about CAD$16/TB for 3�" (~20TB) HDDs vs CAD$80/TB for M.2 (~4TB) SSDs.

    I guess if you need many TBs and you're content with a 2x speedup,
    a dual-actuator drive can make sense, but I suspect that the market for
    those whose performance falls between HDDs and SSDs is shrinking.

    I wonder how power consumption compares for 20TB-range HDDs-vs-SSDs.


    Stefan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Monnier@21:1/5 to All on Wed May 28 12:52:57 2025
    Stephen Fuld [2025-05-28 09:20:27] wrote:
    On 5/28/2025 9:08 AM, Stefan Monnier wrote:
    That seems like a more important benefit: the users get to choose how to
    spread their data depending on their specific use case.
    I don't disagree, though I didn't see any mechanism for the user to specify the unit of interleave. Of course you could do this in the host
    file system.

    If they appear as two LUNs, then the drive can't do the interleaving,
    only the host can.


    Stefan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Fuld@21:1/5 to Stefan Monnier on Wed May 28 10:15:14 2025
    On 5/28/2025 9:52 AM, Stefan Monnier wrote:
    Stephen Fuld [2025-05-28 09:20:27] wrote:
    On 5/28/2025 9:08 AM, Stefan Monnier wrote:
    That seems like a more important benefit: the users get to choose how to >>> spread their data depending on their specific use case.
    I don't disagree, though I didn't see any mechanism for the user to specify >> the unit of interleave. Of course you could do this in the host
    file system.

    If they appear as two LUNs, then the drive can't do the interleaving,
    only the host can.

    Of course the drive can. In general, you have no idea of the mapping
    between what the host calls a LUN/LBA (logical block address), and the
    physical cylinder and head on the drive. You might notice a performance difference depending upon workload, but that is the point of allowing
    the user to specify the interleave factor.

    For example, say the drive chooses to interleave between the two
    actuators every 64K bytes. If a long (say 1MB) request comes in on one
    LUN, it will intermittently tie up both actuators, so if another 1 MB
    request comes in on the other LUN, it will have to wait, but on the
    other hand, when that second request gets its turn, it will complete
    faster. And, of course, if you use command queuing, you may not even
    notice. YMMV.


    --
    - Stephen Fuld
    (e-mail address disguised to prevent spam)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Monnier@21:1/5 to All on Wed May 28 14:16:31 2025
    Stephen Fuld [2025-05-28 10:15:14] wrote:
    On 5/28/2025 9:52 AM, Stefan Monnier wrote:
    If they appear as two LUNs, then the drive can't do the interleaving,
    only the host can.
    Of course the drive can. In general, you have no idea of the mapping
    between what the host calls a LUN/LBA (logical block address), and the physical cylinder and head on the drive.

    Right, but what would be the point of exposing two LUNs if the drive
    does the interleaving? Wouldn't it be "all cost, no benefit"?


    Stefan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Fuld@21:1/5 to Stefan Monnier on Wed May 28 13:37:44 2025
    On 5/28/2025 11:16 AM, Stefan Monnier wrote:
    Stephen Fuld [2025-05-28 10:15:14] wrote:
    On 5/28/2025 9:52 AM, Stefan Monnier wrote:
    If they appear as two LUNs, then the drive can't do the interleaving,
    only the host can.
    Of course the drive can. In general, you have no idea of the mapping
    between what the host calls a LUN/LBA (logical block address), and the
    physical cylinder and head on the drive.

    Right, but what would be the point of exposing two LUNs if the drive
    does the interleaving? Wouldn't it be "all cost, no benefit"?

    The benefit of LUNs is to allow the host issue more than one command at
    a time when the host doesn't support command queuing. It is independent
    of the interleaving decision.


    --
    - Stephen Fuld
    (e-mail address disguised to prevent spam)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From MitchAlsup1@21:1/5 to Stephen Fuld on Wed May 28 22:28:53 2025
    On Wed, 28 May 2025 20:37:44 +0000, Stephen Fuld wrote:

    On 5/28/2025 11:16 AM, Stefan Monnier wrote:
    Stephen Fuld [2025-05-28 10:15:14] wrote:
    On 5/28/2025 9:52 AM, Stefan Monnier wrote:
    If they appear as two LUNs, then the drive can't do the interleaving,
    only the host can.
    Of course the drive can. In general, you have no idea of the mapping
    between what the host calls a LUN/LBA (logical block address), and the
    physical cylinder and head on the drive.

    Right, but what would be the point of exposing two LUNs if the drive
    does the interleaving? Wouldn't it be "all cost, no benefit"?

    The benefit of LUNs is to allow the host issue more than one command at
    a time when the host doesn't support command queuing. It is independent
    of the interleaving decision.

    Seems to me that SR-IOV provides the mechanism to have almost any number
    of in-order queues, each; give GuestOS[5] k virtual FUs to device[19].

    Want overlap and don't care about order, spread the workload around.
    Don't want overlap or do care about order, use a single V device.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stephen Fuld@21:1/5 to All on Wed May 28 16:00:29 2025
    On 5/28/2025 3:28 PM, MitchAlsup1 wrote:
    On Wed, 28 May 2025 20:37:44 +0000, Stephen Fuld wrote:

    On 5/28/2025 11:16 AM, Stefan Monnier wrote:
    Stephen Fuld [2025-05-28 10:15:14] wrote:
    On 5/28/2025 9:52 AM, Stefan Monnier wrote:
    If they appear as two LUNs, then the drive can't do the interleaving, >>>>> only the host can.
    Of course the drive can.  In general, you have no idea of the mapping >>>> between what the host calls a LUN/LBA (logical block address), and the >>>> physical cylinder and head on the drive.

    Right, but what would be the point of exposing two LUNs if the drive
    does the interleaving?  Wouldn't it be "all cost, no benefit"?

    The benefit of LUNs is to allow the host issue more than one command at
    a time when the host doesn't support command queuing.  It is independent
    of the interleaving decision.

    Seems to me that SR-IOV provides the mechanism to have almost any number
    of in-order queues, each; give GuestOS[5] k virtual FUs to device[19].

    I confess to no knowledge of SR-IOV. But absent command queuing, the
    device will only accept one command per LUN. If there were more than
    one, neither the SAS nor the SATA protocol has a way to indicate for
    which command the read data returned is for. The primary thing that
    command queuing provides is that mechanism.


    --
    - Stephen Fuld
    (e-mail address disguised to prevent spam)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Levine@21:1/5 to All on Thu May 29 01:54:35 2025
    According to Anton Ertl <[email protected]>:
    In the present context: If the drive electronics has the minimum
    amount of duplication, why present the thing as two LUNs?

    From the Seagate FAQ:

    Q: Is the development of a single volume drive expected in the future (i.e., the
    drive itself will load balance/optimize by striping workloads evenly across both
    actuators)?

    A: Maybe. It is possible, but there are tail-latency issues with a configuration like this, yet it
    is the simplest way to get plug-and-play performance. There needs to be enough market
    to justify the firmware development/complexity


    And as for what it's intended for:

    Q: What workloads show the best performance benefits over a single actuator?

    A: Exos 2X was designed for hyperscale workloads that focus on low queue-depth random
    read operations (low queue-depths keep command latencies low) and large transfer size
    sequential operations. The highest performance gains over a single actuator will be found
    during high transfer size sequential reads/writes (128KB transfers and larger), random reads
    (all transfer sizes), and random writes (128KB transfers and larger)

    --
    Regards,
    John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
    Please consider the environment before reading this e-mail. https://jl.ly

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefan Monnier@21:1/5 to All on Thu May 29 09:56:51 2025
    Stephen Fuld [2025-05-28 13:37:44] wrote:
    On 5/28/2025 11:16 AM, Stefan Monnier wrote:
    Stephen Fuld [2025-05-28 10:15:14] wrote:
    On 5/28/2025 9:52 AM, Stefan Monnier wrote:
    If they appear as two LUNs, then the drive can't do the interleaving,
    only the host can.
    Of course the drive can. In general, you have no idea of the mapping
    between what the host calls a LUN/LBA (logical block address), and the
    physical cylinder and head on the drive.
    Right, but what would be the point of exposing two LUNs if the drive
    does the interleaving? Wouldn't it be "all cost, no benefit"?
    The benefit of LUNs is to allow the host issue more than one command at
    a time when the host doesn't support command queuing. It is independent of the interleaving decision.

    I don't think it's independent: tying the LUNs to the interleaving
    brings the benefit of letting the users choose the interleaving and
    basically exposing the hardware reality so the host can make best use
    of it. If the interleaving is independent from the LUNs it means the
    sole purpose of the LUNs would be a poor man's command queuing.
    If you want multiple commands in flight, command queuing is the standard solution and it's not like it's rocket science, so why would you use
    LUNs for it instead, given how much more clunky it is to use for
    that purpose?


    Stefan

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Lurndal@21:1/5 to [email protected] on Thu May 29 14:23:16 2025
    [email protected] (MitchAlsup1) writes:
    On Wed, 28 May 2025 20:37:44 +0000, Stephen Fuld wrote:

    On 5/28/2025 11:16 AM, Stefan Monnier wrote:
    Stephen Fuld [2025-05-28 10:15:14] wrote:
    On 5/28/2025 9:52 AM, Stefan Monnier wrote:
    If they appear as two LUNs, then the drive can't do the interleaving, >>>>> only the host can.
    Of course the drive can. In general, you have no idea of the mapping
    between what the host calls a LUN/LBA (logical block address), and the >>>> physical cylinder and head on the drive.

    Right, but what would be the point of exposing two LUNs if the drive
    does the interleaving? Wouldn't it be "all cost, no benefit"?

    The benefit of LUNs is to allow the host issue more than one command at
    a time when the host doesn't support command queuing. It is independent
    of the interleaving decision.

    Seems to me that SR-IOV provides the mechanism to have almost any number
    of in-order queues, each; give GuestOS[5] k virtual FUs to device[19].

    While true, the AHCI specification for the SATA PCI controller doesn't
    include SRIOV.

    nVME on ther other hand, includes SRIOV support specifically for that
    reason.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)