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
Most of what I have discussed in this article could have been implemented over a decade ago!
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
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
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.
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!
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.
This is similar to my years old draft of a 128x CDROM drive that spins the CD at 32X speeds.
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.
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
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
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
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!
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
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.
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
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
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.
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
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
My Email link. copy and past. firstname.lastname@example.org
or is the status "coffee is good" on yahoo messenger