https://blog.seagate.com/enterprises/multi-actuator-technology-a-new-performance-breakthrough/

 

Hopefully this will bring parity checking times on those 10TB+ monsters back to reasonable amounts.

While this is a nice advancement, I do not see it changing things like parity check. Parity check is reading all the data. This dual actuator does not change the number of read heads, or pretty much any other throughput factor.

 

This will address a different problem being seen with high density drives, the IOPs/TB. This is a huge problem seen in large data sets. The current density path put archive disks on a collision path with tape. But tape keeps moving that target and keeping price very low. The problem with keeping a large data set on disk, it has to be useful. Using data means using IOPs. But the IOPs per drive hasn't changed while the TB per drive has grown. This has created a straw to access the pool/lake of data.

This seems more like a bandaid. A neat bandaid, but still....

16 hours ago, c3 said:

This dual actuator does not change the number of read heads, or pretty much any other throughput factor

Well, that depends on the strategy. I could imagine having different types of operation.

Either focused on IO or throughput. That would change the way data is written/spread across the drive.

Pretty much like RAID levels are doing today.

 

2 hours ago, Fireball3 said:

Well, that depends on the strategy. I could imagine having different types of operation.

Either focused on IO or throughput. That would change the way data is written/spread across the drive.

Pretty much like RAID levels are doing today.

 

OK, let me rephrase that.

This dual actuator does not change improve the number of read heads, or pretty much any other throughput factor.

 

The current design is throughput focused. This change does not improve on that (nor it is meant to). The amount of data under the heads does not change due to dual actuators. It may change due to platter count or platter density, but not actuator count. The time to seek and settle does not change due to actuator count. Changing the data is written would change from the current throughput optimized, thus lowering throughput, in favor of increased IOPs. Most of the work shows that dual actuators can be implemented without reducing throughput.

 

There is potential for improved throughput with the multiple read head design of BPMR, which may be used in conjunction with dual actuators. But dial actuators is not the factor. Of course BPMR is meant to improve platter density and that should improve throughput as well.

 

There are several advancing technologies, most are meant to increase density, which often has the easy side effect of improved throughput.

 

1 hour ago, c3 said:

OK, let me rephrase that.

This dual actuator does not change improve the number of read heads, or pretty much any other throughput factor.

Yes it does - unless I'm totally misunderstanding something here...

Given the fact that only one head can read/write at a time in a single actuator coil, it is very likely that a second head that can
position itself independently from the first one can read/write a similar amount of data (in the same time).
Only thing is that data has to be spread accordingly.

Seems like instead of having half the heads on one actuator and half on the other, that they would add a whole second actuator with second set of heads diametrically positioned. That could double throughput (same amount of data could be read / written in half a revolution instead of a whole revolution. Uniquely to unRAD, this would halve the parity write penalty.

 

Not understanding how this splitting of heads on two actuators helps very much unless in concert with a filesystem that somehow understands this and could organize data to take advantage (not obvious how).

15 minutes ago, SSD said:

they would add a whole second actuator with second set of heads diametrically positioned

No, according to the picture, they just use half of the heads on one actuator but based on the same coil.

By separating the actuators they can position 2 heads simultaneously.

A next step could be multiple actuators or ideally one actuator per head.

 

10 minutes ago, SSD said:

in concert with a filesystem that somehow understands this and could organize data to take advantage

Exactly this!

 

 

Already now, they would on average manage much more seek operations/second.

 

If the files are spread randomly over the disk surface, then there is a 50% probability that the second file is on the other half of the drive allowing a seek to be performed to the second file concurrently with a seek to the first file.

 

So without any special optimization, you could get a 50% boost in seek operations per second.

 

The theoretical limit (hard to reach) would be a doubling in number of seek operations/second. Segmenting a database so odd records are on one half o the platters and even records are on the other half, would allow concurrent seeks to odd/even records, or would allow twice the bandwidth for retrieving a large sequence of records.

 

It's even possible to make this drive behave like two disks in RAID-1 and duplicate all data on write and select randomly if the upper or lower half of the heads should be used for read operations.

On 12/19/2017 at 12:04 PM, c3 said:

While this is a nice advancement, I do not see it changing things like parity check. Parity check is reading all the data. This dual actuator does not change the number of read heads, or pretty much any other throughput factor.

 

In theory this dual actuator will increase performance because of the ability to read or write on two heads at same time due to two independent sets of heads.  It would be up to the drive firmware and processor to realize any further improvements.

20 minutes ago, unevent said:

 

In theory this dual actuator will increase performance because of the ability to read or write on two heads at same time due to two independent sets of heads.  It would be up to the drive firmware and processor to realize any further improvements.

Or you, the user, can decide on your needs and then format and use it as if it represents two half-as-large drives in JBOD, RAID-0 or RAID-1 configuration. The OS already contains code to take advantage of RAID-0 or RAID-1 concurrency.

8 minutes ago, pwm said:

Or you, the user, can decide on your needs and then format and use it as if it represents two half-as-large drives in JBOD, RAID-0 or RAID-1 configuration. The OS already contains code to take advantage of RAID-0 or RAID-1 concurrency.

 

My opinion is the goal is to increase capacity of spinner drives while not negatively affecting the performance.  Going to multi-actuator and keeping the costs and reliability in check is the first step given current tech.  But yes, splitting a drive into a RAID0 moves you to SSD-like performance, and there may be a market for that if NAND prices continue to be astronomical.

3 minutes ago, unevent said:

 

My opinion is the goal is to increase capacity of spinner drives while not negatively affecting the performance.  Going to multi-actuator and keeping the costs and reliability in check is the first step given current tech.  But yes, splitting a drive into a RAID0 moves you to SSD-like performance, and there may be a market for that if NAND prices continue to be astronomical.

 

I like this approach. Have the drive be RAID0 internally. Just need smart firmware. That would get you the advertised speed bump! I am getting about 330 MB/sec speed from my RAID0 disk I use for parity (outer sectors), as opposed to < 200 MB/sec operating individually. If these were inside one disk, it would have a heck of an improvement for sequential or random access.

Imagine that each disk surface is treated as a "disk", each having an actuator and head. And these are all combined into a single RAID0 volume internally. That would be very very fast!

1 hour ago, SSD said:

Imagine that each disk surface is treated as a "disk", each having an actuator and head. And these are all combined into a single RAID0 volume internally. That would be very very fast!

But hard to handle the bandwidth in that form factor.

 

If seen as just two disks, then the current SATA interface standard already has the required bandwidth. Optimizing for a large number of concurrent heads means the drive must get many SATA connectors and physically show up as multiple disks for the controller card.

 

I think with current technology, it wouldn't be meaningful to move past four concurrent heads. But for a four-head design, I would prefer two complete head assemblies similar to this disk. So each disk surface can be serviced by two heads. With two heads/surface you would either be able to read each track in half the time, or you could cut the worst-time seek times by not having to wait a full revolution until the target sector showing up under the head.

 

In my view, it's more important to try to cut the worst-case seek latency than to try to get huge speed transfer improvements. Systems that needs huge speed transfers can add additional disks and stripe the data. But the cost skyrockets if you instead have to build RAID-1 with a huge number of normal disks but operating with staggered rotation phase just to try to improve the maximum latency and the total number of seek operations/second.

 

In the end, flash media will be best suited to handle extreme transfer rates or extreme number of IOPS. Optimized variants of HDD are best for really large drives or for handling really huge number of rewrites where flash drives still have problems with wear. And there is a huge gap to bridge between SSD and HDD when it comes to number of seeks/second.

I was thinking the drive look and act like a SATA drive, with one SATA connector and one power connector, but under the hood, through firmware, could be running a RAID0 across the multiple actuators. There are external enclosures where the capacity of two drives are combined to appear as a single larger drive. This would be similar.

11 hours ago, Fireball3 said:

Given the fact that only one head can read/write at a time in a single actuator coil,

Ah, there is your misconception. All heads can read at once. The all heads read all the data in the track on all platters without moving. The whole cylinder can be read without a seek. This is throughput optimization disk have been using for sequential reads. It is pretty hard to beat. But as density grows, it may be time to give up some of that for more IOPs.

 

This is also why throughput drops so much for non sequential reads. Mechanically it is too easy to read all the data around a single random request, and dump it. So, read ahead always has lots of data to try a second guess the next request, or next or next...

 

A single head is far slower than the whole cylinder, and that includes all the encoding overhead, so the yield is well below those nice sequential burst speeds seen on parity checks.

 

Most disk explanations leave out the real world case of multiple platters.

 

Here is a class on disk basics from UT.

 

Spinning disks have been optimized and tweak may times over for decades. They are far more than just a simple read head at the end of a single actuator. The idea of multiple actuators is not new, and this is not the first time disks have been built with more than one. Us longer term people will recall the Chinook from the last century (or the IBM 3340 for those even longer in the tooth).

Back then we talked of RAID as redundant array of inexpensive disks vs SLED single large expensive disk. But that was after we hole punched the diskette and flipped it for doublesided use

Edited December 21, 20178 yr by c3

2 hours ago, SSD said:

I was thinking the drive look and act like a SATA drive, with one SATA connector and one power connector, but under the hood, through firmware, could be running a RAID0 across the multiple actuators. There are external enclosures where the capacity of two drives are combined to appear as a single larger drive. This would be similar.

Exactly. It's just that if you want 8 heads that can operate concurrently and transfer data, like you suggested, then you don't have enough bandwidth from a single SATA data cable. With just two concurrent heads, SATA-600 has enough bandwidth. With 4 concurrent heads, SATA-600 will at times be maxed but you can still improve the total throughput since you get less time with no transfers while the disk waits for the next seek to finish.

 

The disk mentioned in this thread will most probably look identical to a normal disk. The only change recommended is a translation from LBA to actual sectors so the first 50% of the sectors span the first half of the surfaces and the next 50% span the remaining surfaces. This would allow the drive to be partitioned at 50% and the two partitions then used as RAID-0 or RAID-1.

5 minutes ago, pwm said:

Exactly. It's just that if you want 8 heads that can operate concurrently and transfer data, like you suggested, then you don't have enough bandwidth from a single SATA data cable. With just two concurrent heads, SATA-600 has enough bandwidth. With 4 concurrent heads, SATA-600 will at times be maxed but you can still improve the total throughput since you get less time with no transfers while the disk waits for the next seek to finish.

 

The disk mentioned in this thread will most probably look identical to a normal disk. The only change recommended is a translation from LBA to actual sectors so the first 50% of the sectors span the first half of the surfaces and the next 50% span the remaining surfaces. This would allow the drive to be partitioned at 50% and the two partitions then used as RAID-0 or RAID-1.

 

SATA-12?

1 hour ago, c3 said:

Ah, there is your misconception. All heads can read at once. The all heads read all the data in the track on all platters without moving. The whole cylinder can be read without a seek. This is throughput optimization disk have been using for sequential reads. It is pretty hard to beat. But as density grows, it may be time to give up some of that for more IOPs.

In theory, a disk should be able to place all heads on top of individual tracks and read concurrently from every head. But it really isn't so easy to actually manage this, since the precision needed is so extremely high and the disk needs to compensate for temperature variations.

6 hours ago, SSD said:

 

SATA-12?

SAS-3 (12 Gbit/s) and comming SAS-4 (22.5 Gbit/s) would be possible interfaces.

 

But is there any SATA alternative besides SATA Express that manages 12 Gbit/s? And there isn't much support for SATA Express currently. And M.2 isn't a suitable form factor for a HDD.

PCIe 3.0 x16 @32 GB/s

 

It will get crowded in the PCI bus.

 

On 12/22/2017 at 12:24 AM, Fireball3 said:

PCIe 3.0 x16 @32 GB/s

 

It will get crowded in the PCI bus.

 

SATA is rated in Gb/sec and PCI in GB/sec

 

SATA III, version 3.x, SATA 6Gb/sec has 600MB/sec throughput.

 

PCI Express Gen 3, most numbers like 32GB/s are full duplex and twice any theoretical read or write rate.