Home - Contact Info - Articles
- Files - Links - Adventures - Other Stuff
[ Note by JT: This is my response to a question in the Compuserve Benchmark forum. I had been conversing
about my favorite topic (disk drives) and mentioning servo sectors and data sectors. The writer quite
properly asked me to clarify my terms. ]
The confusion arises, I think, from two causes. First, the terms in day-to-day use in the industry don't
make it explicit what kind of "sector" we're talking about, that is, whether it's a servo sector
or a data sector. Second, when one is designing the mechanics of a disk drive, one doesn't worry much
about the data; the mechanical engineers design the hardware, the servo engineers design the servo, and
the read/write engineers handle the data. We only talk when we have a cross-discipline problem. Of course,
that means only once or twice a day! But it turns out that there's more mechanical-to-servo interaction
You know that disks are laid out with concentric cylinders or tracks of data, and that the data isn't
arranged in a spiral as it is on a CD.
The surface of a current hard disk that uses "embedded servo" or "sector servo" technology
has two kinds of data recorded on it--servo information and user data. Both the servo information and
the user information is written in discrete units, sometimes called "sectors" and sometimes
called "blocks". If one isn't careful to refer to "servo sectors" and "data sectors"
explicitly, one creates confusion, as I did.
The servo data is written only once, at the factory, and never re-written afterward. The user data has
two sub-categories. I don't know the formal names for them (or even if formal names exist), so I'll call
them "format data" and "variable data". The format data is generally written only
once, though it is possible to rewrite parts of it. The variable data includes everything that's written
when you write a file to disk, so it includes ECC data and FAT (or equivalent) data in addition to your
A disk drive has a fixed number of servo sectors per track. That number is constant across all tracks
and across all surfaces of the drive. Furthermore the servo sectors are written synchronously on the disk.
The beginning of each servo sector on each track is physically adjacent to the beginning of the corresponding
servo sector on each adjacent track. The servo system uses the differences in the recorded patterns on
adjacent servo tracks to define the track centerline.
A current "zone-bit recording" or "variable data rate" disk drive has a variable number
of data sectors per track. This is different from the old MFM and RLL drives that had all the user data
recorded at a single data rate. Variable data rate recording was implemented to get more data on the disk.
At the ID of a disk, the track length is roughly half what the length is at the OD, so if you record at
a constant data rate, thereby getting a constant number of bits of data per revolution, you record at
about twice the linear bit density at the ID as you do at the OD. If you can record twice as fast at the
OD, you get the same bit density and twice as much data per revolution.
Data sectors are currently defined with a fixed size, usually containing 512 bytes of true user data.
The sector itself usually contains 600+ bytes of data with all the overhead stuff, but it is always a
fixed size. So if you record at a variable data rate, you get a variable number of data sectors per track.
Current technology does require that a complete data sector exist on a single track, though it is possible
to split a data sector across a servo sector.
You can see that one could theoretically have a different data rate for each of the 6200 tracks on a Viking
drive, but it turns out to be convenient to divide the surface into 16 zones. Each zone has a constant
data rate and a constant number of data sectors. The number of tracks per zone has to vary a bit to make
all the numbers come out even, but most zones have the same number of tracks, again for convenience. That's
a very incomplete discussion of disk layout, but maybe it will give you some insight.
>> Using the range for the Viking you suggest of 150 to 240, I'm of the opinion that what happens
is that the first date zone might have 240 sectors [or spokes or servo wedges] per track [SPT], the next
data zone might have 220 SPT, the next might have 190 SPT, ... and the last would have the 150 SPT. <<
The first data zone might have 240 data sectors and does have 72 servo sectors (or spokes or wedges) per
track. The next, as you say, might have 220 data sectors, and it has 72 servo sectors. And the last might
have the 150 data sectors and the 72 servo sectors.
[ Note by AD: In attempting to express the differences between ID and ID-less recording formats I actually
eliminated an important feature that John Treder reminded me of how important it was. His comments will
follow my ASCII art to show the "big idea" that I removed in the process of editing the ASCII
AD's ASCII art of a single track in a ID-less recording format
sector sector sector sector
... [data] [data] [data] [servo] [data] ...
Previously (traditional) recording format would have IDs where each ID stores track, head, sector and
CRC information. The previously mentioned ID-less format increases the amount of data that can be stored.
header sector header sector header sector
... [id] [data] [id] [data] [servo] [id] [data] ...
^ ^ ^ ^
| | | |
gap gap gap gap
[ Note by AD: John Treder comments on the "big idea" that Albert Dayes accidently removed. ]
In the course of tinkering with the ASCII art, you simplified out one factor that I think is rather remarkable,
and that's the fact that data sectors can actually be split into two pieces, starting on one side of a
servo sector and ending on the other. That's true for both ID and ID-less data layouts. And in fact it's
the biggest of the non-obvious tricks that makes the combination of sector servo and "constant-density"
When Conner started, they were using constant data rate recording. Every track had the same number of
data sectors on it. Therefore they could plan to have an integer number of data sectors between each servo
sector. Easy to think about and all that.
But you can get (ideally) 50% more data on a disk if you use constant density recording instead of constant
data rate. If you use constant density, however, you need to have a variable number of data sectors per
track. If you insist on having an integer number of data sectors between servo sectors, you throw away
nearly all the advantage of variable data rate. So someone (I don't know who or where) invented a way
to "split" data sectors across a servo sector. Suddenly it became practical to put almost the
"ideal" number of data sectors on each track, and constant data rate recording became "compatible"
And that's what I was getting at with my original ASCII art that had:
... data data da|servo|ta data data data da|servo|ta data ...
split data sector
In fact, the original Barracudas had a dedicated servo surface because Seagate's ex-CDC engineers in Minnesota
didn't know how to do the split-sector trick. They learned in short order, though!
On Katana (Quantum's internal project name for Quantum Atlas 4 (SCSI) and Fireball +KA (IDE); they're
the same except for the interface), there are 124 servo sectors per track, and from 234 to 383 data sectors
per track. So there are 1.887 data sectors between each servo sector at the inside and 3.089 at the outside.
If you didn't split data sectors, you might throw away 11 data sectors at the outside, it's only about
3%. But at the inside, you'd have to throw away 110 data sectors, or nearly half the track's possible
If you work things out in complete logical detail, it takes a lot of drawings and thinking, and it works
out that you lose a little over 1/3 of the benefit of constant data rate if you don't split data sectors.
Copyright © 1999 by Albert Dayes and John Treder