[kijin]

Throughput tends to increase with storage density, because more data is stored in the same length of physical track.

Consumer-grade HDDs barely managed 100MB/s 10 years ago. Now they can often do 200MB/s, and enterprise disks are even faster. With these much larger Seagate drives I guess SATA will be the bottleneck, not the drive's sequential read/write speed.

[dragontamer]

SATA3 is 6Gbps at 8/10b encoding: or 600MBps.

SAS is 12Gbps or 1200MBps (I don't know if it uses 8/10b encoding, but I'll assume that for simplicity)

------------

Hard Drives are no where close to breaking the SATA3 barrier, let alone the enterprise SAS 12Gbit barrier.

[AtlasBarfed]

You're probably still correct, but what I saw from the immediate next generation was something like 9 platters and two or more independent read/write heads.

So we might be headed for what used to be a single write head (and its single throughput stream) to double, triple, or more.

Especially since the additional read heads enable the datacenters to scale shared object storage more effectively with more dense drives, which seems to be the main customer/application for HDDs at this point.

[Sohcahtoa82]

I remember a long time ago when I upgraded my motherboard and was pleasantly surprised that my SSD suddenly became twice as fast. Didn't even consider that I was switching from SATA2 to SATA3, was more interested in my CPU upgrade.

On an unrelated note, are you the same Dragontamer that I've met and played with at PDXLAN? Or do you just happen to use the same alias?

[dragontamer]

> On an unrelated note, are you the same Dragontamer that I've met and played with at PDXLAN? Or do you just happen to use the same alias?

Unlikely me. We must have the same online alias (it is a very common alias in my experience...)

[deelowe]

I'd like to see a graph of density versus iops over time. It definitely feels like the gap has been widening for quite some time just based on how long my ZFS arrays take to do a scrub.

To answer the OP's question, it seems to me that after around 12TB or so, it makes more sense to move away from implementations that require rebuilds such as raid 1, no raid, or jbod solutions.

[dragontamer]

Random IOPS is and always will be stuck at 240 IOPS for a 7200 RPM drive.

7200 RPM / 60 == 120 rotations per second. A "half-rotation" to move the typical data on the disk to the head (half the data is within the first half-rotation, the other half of the data is within the 2nd half rotation).

If you want to reach the data faster, you need to physically rotate the disk faster: such as a 10,000 RPM drive, 15k, or 20k drive. To allow for faster rotations, you shrink the drive to 2.5" or even 1.8". Alas, SSDs have taken over this niche entirely, so we only really have 3.5" and 7200 RPM drives anymore.

[magicalhippo]

And if you have a sufficient number of fairly sequential operations in parallel they start to look very random[1][2] to the storage system.

[1]: https://www.youtube.com/watch?v=yHgSU6iqrlE (presentation)

[2]: https://www.snia.org/sites/default/files/SDC/2019/presentati... (slides, page 41)

[mtone]

Having dual actuators (Seagate's Mach.2 branding) can increase IOPS by having 2 heads process the queue in parallel. That should bring a noticeable improvement, but it's true that it doesn't apply to sequential random (just like NCQ didn't by reordering the queue -- you need a queue).

Not sure if there will be consumer drives with this eventually or if the cost is too prohibitive.

[dragontamer]

Except we can already achieve that kind of IOPS increase: by simply using two hard drives in parallel (be it RAID0, or even RAID1 if your driver is willing to split the reads between hard drives).

A multi-actuator drive isn't really "one hard drive" anymore, its really just two hard drives ganged together. While more physically convenient, it doesn't seem to really offer the true 2x increase we're looking for.

Actuator#1 cannot give more IOPS over the data that Actuator#1 is assigned over. You only get more IOPS if you can split the work between the two actuators. Same problem as RAID0 or RAID1 multi-read hard drives (you gotta figure out a way to "split the work" to get RAID0 truly 2x the IOPS).

[Dylan16807]

RAID0 can't give you a true 2x increase, because reads and writes are constrained to a particular device, and big reads tend to require both drives working together.

RAID1 can give you a 2x increase in reads, but suffers even more than RAID0 when it comes to writes.

Dual actuators, implemented in a straightforward way, can both access the entire drive surface which means they can give you a true 2x increase. Sometimes even better than 2x, because each arm can focus on one side of the disk. For read/write workloads it completely outclasses RAID.

[notacoward]

> because reads and writes are constrained to a particular device

That constraint means nothing here. You can issue two parallel reads to two drives in RAID-0 just as easily in RAID-1. The only case where this doesn't work is where you're reading more than 2x the interleave size and you're issuing separate requests for each interleaved chunk. With command queuing, a smart storage system should even recognize the pattern and buffer to reduce the damage, but you'll still pay a cost in extra interrupts and request handling though so it's better to learn about scatter/gather lists.

> they can give you a true 2x increase

I already explained why this isn't actually the case, and have observed it not to be the case with multiple generations of dual-actuator drives. Stop presenting theories based on misconceptions of how disks and storage stacks work as though they were fact.

[mtone]

SSDs achieve their speed in part by combining multiple independent NAND channels under a single controller - each channel is more or less equivalent to an actuator. Their speed vary greatly based on workload parallelism, yet it's still very much one drive.