Zarcon Dee Grissom's Idea Page
Updated 03FEB2006
Home > Ideas > The Faster Hard Drive
The Faster Hard Drive
Lets Go ALL OUT!
This “New” magnetic orientation, is shall we say, optional. This is a build it NOW design.
We will settle for no less then sustained reads of  200MBps (NOT bits) Output bandwidth.
Most of what I have discussed in this article could have been implemented over a decade ago!
Main Menu


Meet the computers

About Me



Working on the rest of the pics...

Your not going to tell me that the current bread of PATA/SATA drives employ any of these ideas. the single plater side drives (the smallest size of a model) has identical I/O performance as its larger siblings (with multiple plater sides being used). The caching schemes are adversely affected by fragmented files. And the majority of these drives today utilize commodity micro-controller chips.

Lets go ALL OUT!

It's time to let Team OSWATT, draft out a HDD (Not solid state) for leave the interface in the dust performance. We have to keep in mind that Team OSWATT caters to very few users. Price, Power consumption, And Noise levels are not considerations with our designs. We build Saturn-V rockets, not luxury sedans. If you want it quiet, put it in another room or closet.

The prerequisites of this peace of gear.
This is going to be a 3.5inch or 5.25 inch(CD-ROM) sized hard disk, with spinning platters (No Film-Stack-chips/Core-Stack this time around). It will conform to ATX 2.0 specifications and ATX 12v2.1 power requirements. Beyond that we have up to 100Watts of 12V juice, and 10 watts of 5V juice  at our disposal. We will settle for no less then sustained reads of  200MBps (NOT bits) Output bandwidth, with write operations happening at the same time. And, no less then 350MBps from cached files.

lets go back to the spinning disc.

Lets not reinvent the wheel. We will start with a 10,00RPM, four or two platter drive housing, platters, and motor. The arms are also good enough. the ribbon going to the heads, and the heads may have to be changed.

This “New” magnetic orientation, is shall we say, optional. This is a build it NOW design.
So what do we have already. We have the sector tracking, and cylinder alignment already in the basic drive control circuits. Lets Improve it.

stripe the data across platter sides.
Give me one virtual head, and four or eight physical heads.
four head to bit diagram
Now for every byte we read off of each head in the bank of platters, we have obtained four or more bytes of raw data. What a concept, This is part of what striping RAID dose!
Bytes on heads
What ever overhead there is for sector and cylinder identification zones, is meaningless to us, that is what the head alignment control circuits deal with before we even see data. So lets say that this eats up eight bytes before we start to see actual data. We do business in five-hundred-and-twelve byte sectors, no less. A required and small overhead for a disk drive.

We've just cut the read spin time for a sector, from 512 bytes passing each head to 128 bytes per head in a two platter drive(a four times boost in bandwidth), or a measly 64 bytes in a four platter drive (an eight times boost in bandwidth).

I wont tread past four platters. There is probably several very good reasons why manufacturers haven't already ventured past five platters in the newest drives.

Command Queuing to multiple drive arms.
This is not enough to satisfy our needs. lets add another set of read/write heads on another Arm, We can do that.
Dual Arm Drive pic

This is similar to my years old draft of a 128x CDROM drive that spins the CD at 32X speeds.
CDROM Eyescdr911

This simple addition, adds parallel read performance like no other. One Arm could be heading to read/write a sector in the center of the drive platters, while the other is reading/writing a sector on the out side of the platters at the same time.

(Consecutive cylinder read to cache scheme)
here one arm is reading a cylinder, while the other arm is reading the next cylinder in advance. Then both arms skip a cylinder, and start the reading process again on the next pair of cylinders.
(Multiple Simultaneous Read to cache scheme)
Here the separate arms are reading two completely different requests at the same time.

In either case, We have effectively doubled the drives potential threw put, and at least reduced seek times.

Now to take this simple concept to the level of the former mentioned CDROM. You will notice that there are actually four eyes in that CDROM drive. With four arms reading and writing data to and from this drive, we can quadrupole a drives read/write performance, and reduce seek times to a bare minimum.

Quad Arm Drive
Combined with striping data across the heads, this will deliver a sustained four or eight times conventional bandwidth, and a peek of sixteen or thirty-two times conventional bandwidth. 
And this is Just the drives internal mechanics we've covered so far! Granted the four arm version of the OMG-Drive would require a CDROM sized mount in a computer. The Performance gains would be well worth the cost in size.

Really big read caching scheme

I'm not going to suggest A most retrieved or similar algorithm to decide what to cache or not to cache. I want this to be an intelligently predictive cache. I'm still undecided as to the pro's and cons of a write buffer in this drive.

Lets Understand the data on the drive.
Most drives fall under two categories when they are installed, program, and/or data drives. Program drives have executables on them that require fast loading to RAM for programs to start up quickly, including the operating system. Data drives require fast Listing and retrieval of multiple small segments of data for programs to use.

In both cases we can assume that the file listing stuff will be used the most, so lets keep it in cache. Saving it to disk when it is updated or changed by the OS.

Optimizing Cache for NTFS/FAT/FFS/UFS/RFS/JFS reads.
Every OS has some sort of a list of files on it's drive(s). And this list can be very predictable to it's location. FAT is on the first couple of sectors on the drive. The master block or first segment of a segmented list is also on the first couple of sectors. Beyond this, the master block lists where the next segment of the file list is on the drive, and so on. Lets put this in cache.

This can give us a really good idea as to where the next read or wright operation will take place, as the OS will likely stop reading the list of files at the point where the file is that will be wanted. Therefore the drive can go ahead, and commit a arm to start moving to the cylinders indexed in the last retrieved part of the file list.

Boot time caching, and restarts on SATA.
During Boot up, two kinds of activity can be expected. One consisting of a complete operating system loading off of the drive, and one with next to nothing being transferred at all. The drive can quickly learn from this at boot up. Either it is a boot or solo drive, or a data only drive. Second hint is looking at the extensions of the files at the cylinders read.

Just in case, as the BIOS is doing it's RAM check, the drive can go ahead and load the File list and boot record into cache. This will instantly tell the drive if it should load the first sixteen sectors and the last sixteen sectors on the drive into cache for BSD, the first couple of Megs into cache for windows, etc.

How can the drive know if the computers reset button has been pressed? Usually a BIOS will tell a disks to start spinning, ask for what kind of drive is attached to the controller, and what interface speeds it support. This simple activity alone, if SATA dose not have a reset command, can hint to the drive to start caching the boot record and OS files if there on the drive.

Give me just enough data to send out, till the arm(s) get there.
Now that we can understand the partition table, and file listing. We can know what the cluster size is, and where the empty spaces that don't need to be cached are. We can start off the day by caching the first two sectors of every cluster on a drive. Better yet cache the files most accessed excluding Operating System files like the kernel, and the first few sectors of every file on the drive.

Now that we have almost guaranteed, that at least a portion of a file that will potently be read is in cache. Have a mechanism for preemptive head movement. We have improved drive I/O performance, and seek time dramatically.

Is it the controller chip that is slowing me down?

Why do manufacturers insist on using slow cache chips on there drives? Why is this world stepping away from AND and OR gate circuits in favor of programs? Programmers apparently are cheaper then burn plants and glass.

Data integrity.
binary question mark ones and zeros
Several schemes can be used to guarantee accurate data. One is with parity, another has to do with magnetic field strength, and the third involves comprehending the data.

Need not write eight bits to each head, to change one byte!
Byte Change bits PIC
Also with the bits split up to different heads, the drive dose not need to read All eight bytes to change the parity bits for the one byte.

Chances are, that an existing file that is being changed by a text editor or data base is already in cache, and has less then an entire 512Byte change. We can compare the new sector to the old one, and wright only the changes to the disk platters. This drastically reduced head usage in wright operations, and can take place on the fly as the sector is being righten.

Second off, single character changes only need a single block to be change. This includes the changed character, and it's associated Parity bits.

XOR and data striping in hardware, NOT firmware.
Some operations are smaller and faster as hardware circuits, then as a programed sequence of commands in a processor.

XOR testing operations can be tested for “good” in hardware, a false XOR test result can trigger a macro to look at repairing the faulty data. First is the cache matching the data on the drive? is the data on the drive good? Can the cache be refreshed, or dose the drive need to have the magnetic field strengths verified?

There are two different ways the drive can stripe the data on the platters, one involves bits split up to different heads, the other involves sending bytes to each head. The split up bit striping scheme allows data to start flowing out of the drive sooner then the other. And both can be accomplished with a register and a bit-switch. A.K.A. No overhead.

What dose the BIOS see?

The two plater drive would have half the sectors as the four platter drive. So if each platter would originally have eight sectors a side, the final platter setup in the BIOS would be 32 sectors or 64 sectors depending on number of platters. LBA is LBA regardless of disk geometry.


Why bother with multiple arms?
Clearly current products are NOT able to perform any faster with the latest and greatest advancements, So Drastic measures are required to meet current interface potential threw puts. We at Team OSWATT there fore are insistent on at least two arms, NOT one in each drive, and substantial Read Cache sizes of at lest 512MB of 1GHz Video memory, Minimum.

Can Hard drive manufacturers meet the challenge?
The current onslaught of  15kRPM SCSI drives leaves the 10kRPM drives open for manufacturers to migrate to the PATA/SATA markets, without jeopardizing there SCSI market leaderships. Implementing any of these ideas across there SCSI and ATA markets at the same time would also preserve there SCSI market investments.

The simplest of these ideas could be implemented with a change in the control board on there drives alone. All the investments in platter densities, heads, arms, and so on would remain unchanged. The Mechanical hardware dose not need to be changed to apply the data striping across heads.

We would much rather purchase this drive in a store, then insult manufacturers by building it from scratch. Most of what I have discussed in this article could have been implemented over a decade ago!

Will Hard drive manufacturers meet the challenge?
Short answer is, Hell No!

As of current, SCSI has the playing field for performance from almost ALL drive manufacturers, leaving SATA a position on the bench. Witch enrages All of us at Team OSWATT and apparently people at review sights. As for Western Digital, Nothing for over two years in the Raptor family, leads us to think they have been bribed by somebody that thinks there a gorilla.

Western Digital just released a 150GB Raptor, that performs insignificantly better then the former two Raptor drives. A performance gain solely achieved by increased data density on the platters. With a bottom end I/O of about 60MBps over 50MBps, and peek of 81MBps to 73MBps. Looking at it another way, each platter in the WD740GD has 18.5GB a side, where as the WD1500ADFD has 37.5GB a side. So simply put, a higher data density provides more data passing the heads for each rotation. This is like pooling the suffocating hand off our snorkel for a breath of what could be, as we drown in lack of performance.

Calculated numbers

Assuming that a 10,000 RPM drive has a bottom end IO of about 50MBps (example drive 75 gig Raptor IO at THG). Four times 50MBps would be about  200MBps. Eight times that is about 400MBps, which exceeds the SATA 3.0Gbps (375MBps) hardware limit.  Don't forget about LBA/CHS requests and Protocol overhead.

A two platter internally striped ATA133 drive with a single arm, would outperform the current selection of SATA drives and then some.

A four platter internally striped SATA-2 drive with NCQ and single arm, would slaughter every drive on the market. At current advancement rates, it would take hard drive manufacturers years to catch up.

Forget about the four arm variants of this concept drive. There isn't an interface that could keep pace with the sustained eight-hundred or sixteen-hundred Meg-Byte per second I/O this drive can dish out, with the exception of Graphics, Memory, and Front Side Buses. That and there is a political disadvantage to the four arm drive. Constructed wrong, its internal guts almost looks like a nazi swastika.
Quad Arm DriveQuad Arm Drive

Food for future thought

Can a hard drives electronics be intelligent enough to know when a virus is trying to infect files on the hard drive? And would such a feature be desired, or feasible?

At what point, do you start loosing bandwidth, when a device is faster then it's bus? How far can a SATA controller be pushed before it starts bogging down data transfer due to two many requests in que?

Are current SATA controllers tested at longterm sustained peek bandwidth without overheating? 70MBps peak I/O is a far cry from sustained 200MBps, let alone sustained buss saturation of 375MBps each from multiple drives.

In a RAID 0 setup this drive could achieve a sustained I/O of 375MBps per hard drive, for a grand total of 750MBps on two drives. Can current SATA RAID controllers handle this kind of bandwidth without internal limitations, bottlenecks, or melting down?

How would a SATA controller handle four of these drives connected to it? We have to breach limitations of Motherboard I/O eventually with additional drives. Is there a SATA command for telling the hard drive to “wait! I haven't sent out the last gig of stuff you already gave me”?

Valid XHTML 1.0
My Email link. copy and past.  
or is the status "coffee is good" on yahoo messenger