why no multi servo HDDs

[exdeath]

It's too little too late for the HDD, so it's a moot point now.

But I've always wondered, why not multiple servos? eg: independent sets of heads in opposing corners of the drive enclosure.

Would drastically improve HDD random IO by *more* than double and wouldn't be difficult to implement. Much easier than implementing a 30k RPM spindle at any rate.

Onboard MCU positioning the heads and listening for guidance feedback is still millions of times faster, more than enough time to sort and interleave queued operations between heads within a single revolution. I think I could even have fun writing that firmware.

 

[paul878]

Conner Chinook back in the 90s had two sets of heads.

 

[greenhawk]

I remember reading about one in the late 90's. But the second was a read only head with the intended purpose the second head had a separate data connector so could be better in a server enviroment were read only access was needed at all costs.

Though some software would have turned that into a good dual headed drive without too much issue.

Cost and complexity I think are the reasons it is not a common feature.

 

[pitz]

Seagate made one. Go look up the ST12450W, Seagate Barracuda 2 2HP. Such drive had a standard Fast/Wide SCSI-2 interface (20mb/sec), and was able to transfer roughly 12megabytes/second. I/O transactions per second count was roughly double that of a single actuator drive.

Biggest problem was cost. For what such drives cost to produce, and their relatively small volume, going with a RAID-1 was far more economical.

It took almost a decade for the industry to produce a drive that was acutually the same, if not faster, in terms of IOPS. At the time, 170-180 seeks/second was what one could get out of high-end SCSI 7200rpm drives. The 2HP basically doubled that, so 300-350 seeks/second. Even the best 15k RPM drives today would have trouble matching that!

Remember, a good SCSI drive, Seagate 2gb, at the time, cost around $1600. Circa 1995.

These days, obviously, for high IOPS scenarios, SSDs are preferred. But yes, Seagate did try a dual actuator drive, but it wasn't a commercial success and the idea was never tried again to the best of my knowledge.

 

[groberts101]

I would imagine a drive with 4 servos would literally require a controller nearly as smart as an SSD's to really capitalize on that many IOPS and throughput. Not to mention the resultant ECC that would be necessary to keep the data straight.

 

[pitz]

I would imagine a drive with 4 servos would literally require a controller nearly as smart as an SSD's to really capitalize on that many IOPS and throughput. Not to mention the resultant ECC that would be necessary to keep the data straight.

Not really. Obviously the firmware designer would have to provide for a mechamism to 'lock' certain sectors that were being written (no different than the same that has to be accomplished with filesystems in multitasking systems!). And the firmware designer would probably want to do some optimization within the command queues (ie: tagged command queuing) to pick the optimal actuator.

ECC schemes would be unchanged from other drives.

Overall reliability and manufacturability probably would be larger concerns. The people who need drives with high IOPS counts, probably also need redundancy, so its generally cheaper to sell them on increasing drive count (through RAID), than it would be to sell them a niche solution. Remember, the more parts in a drive, the less reliable. The Barracuda 2 2HP needed, IIRC, 10 or 11 platters to achieve a mere 1.8gb of capacity + a servo platter -- which means that such a drive contained 40-44 heads. Many points of failure, to say the least, especially on a drive that probably was bought so some database could pound the sh*t out of it.

(BTW, I giggle these days when some newbie runs around claiming that 5-platter drives probably will have terrible reliability....when they were building 11-platter drives, in 3.5" format, back in 1995, and putting 44 heads into a single drive to boot.....all the Seagate Barracuda drive failures I had back then were because of Seagate's poor quality electronics....never once suffered a mechanical event on a Seagate Barracuda SCSI...)

 

[groberts101]

That may be true to some extent.. but I do know that firmware alone will not do all that on its own.

Takes processors or sata chips to tally that much info up and make sense of it all in such a short time frame. Otherwise we would have been just waiting for firmware upgrades to increase speeds with every new generation.

Far more to it then just firmware code alone I'm afraid. If it was that simple?.. we wouldn't need ROC.

Definately right on target about more points of error/failure as hardware becomes more complex though.

 

[Soulkeeper]

I always thought it would be interesting to have a read/write "strip" that ran across all tracks instead of an actuating arm. Something like that would likely be costly tho.

 

[pitz]

That may be true to some extent.. but I do know that firmware alone will not do all that on its own.

The Seagate drives were indistinguishable, from the point of view of the user, from drives with just single actuators. Of course, without tagged command queuing, it would be awfully difficult to keep the dual actuators actually running. Such a drive would perform best with significant queue depth, where an algorithm could actually sort through the stuff.

Takes processors or sata chips to tally that much info up and make sense of it all in such a short time frame. Otherwise we would have been just waiting for firmware upgrades to increase speeds with every new generation.

This doesn't make any sense. A hard drive is a self-contained embedded computer, feedback control system, etc. The engineering that goes into designing/building a hard drive is just as complex, if not more complex than actually building a 'computer' itself.

Obviously there are physical limits to the heads, the media, etc., which are limitations on overall system performance.

Far more to it then just firmware code alone I'm afraid.

Not really understanding what you're trying to say. Obviously the engineers at Seagate resolved the problems that going with double actuators faced in delivering a drive, with the processors, DSPs, and interfaces that were available at the time. The drive failed because it was not an economic success.

 

[pitz]

I always thought it would be interesting to have a read/write "strip" that ran across all tracks instead of an actuating arm. Something like that would likely be costly tho.

If you know how to fabricate such a device....

 

[groberts101]

Obviously the engineers at Seagate resolved the problems that going with double actuators faced in delivering a drive, with the processors, DSPs, and interfaces that were available at the time. The drive failed because it was not an economic success.

yeah.. I hear what you're saying.. but I was referring to todays speeds and data requirements. Either way.. it's all just speculation anyways.. but I imagine the controller would be similar to perhaps the ability of say the XT hybrid drives in the way they can cache and burst data to increase throughput as a whole.

IOW, I doubt that the "computers processor" of these current HDD can deal with 4 servos worth of data. TCQ.. NCQ.. or otherwise. As mentioned above.. it would be just like saying that we simply need better drivers/firmware rather than a faster ROC on our raidcards.

Driver/firmware can only do so much and the rest must be handled by the hardware was my point. Dunno.. maybe they can keep up though. If that's the case though?.. maybe we need HDD parts running our SSD's? lol

 

[Elixer]

I always thought it would be interesting to have a read/write "strip" that ran across all tracks instead of an actuating arm. Something like that would likely be costly tho.

Then they shouldn't spin the platters, and just move the heads. Like the old dot matrix printers.

In all seriousness, I know they had test models of what you describe, but it had too many issues to be commercially viable.

 

[pitz]

IOW, I doubt that the "computers processor" of these current HDD can deal with 4 servos worth of data. TCQ.. NCQ.. or otherwise. As mentioned above.. it would be just like saying that we simply need better drivers/firmware rather than a faster ROC on our raidcards.

So they develop a faster ASIC. Big deal. SSD controllers can toss around 600gb/sec or more, so certainly, it wouldn't be a huge deal for 4 x 150mb/sec channels in such a drive...

Driver/firmware can only do so much and the rest must be handled by the hardware was my point. Dunno.. maybe they can keep up though. If that's the case though?.. maybe we need HDD parts running our SSD's? lol

Hardware runs the firmware. As impressive as drive technology is, and as much DSP is involved with the PRML read channels, the sort of processing power needed for a HDD really isn't a big deal these days for the sorts of processors they use on HDDs.

 

[exdeath]

Then they shouldn't spin the platters, and just move the heads. Like the old dot matrix printers.

Better yet just have a giant array of stationary independent GMR cells on a wafer, eg: MRAM. :awe:

 

[exdeath]

So they develop a faster ASIC. Big deal. SSD controllers can toss around 600gb/sec or more, so certainly, it wouldn't be a huge deal for 4 x 150mb/sec channels in such a drive...

And ironically that 4 x 150 mb/sec would be max sequential and the lowest load on the controller. Going worst case with random IO where this would help the most, and IOPs would be highest, the controller is still waiting more often than not. Eternity / 4 still = eternity for a reasonably adequate MCU.

Hardware runs the firmware. As impressive as drive technology is, and as much DSP is involved with the PRML read channels, the sort of processing power needed for a HDD really isn't a big deal these days for the sorts of processors they use on HDDs.

Right. Car engines and hard drives both look like they are standing still even with only a 25 MHz 16 bit MCU. The actual handling of data block streaming and error checking can even be force fed through ASIC/DSP/DMA if need be. The MCU can be concerned with handling IOPs, sorting, servo feedback, positioning etc.