LogicSmith
Home - Contact Info - Articles - Files - Links - Adventures - Other Stuff - Dual Monitor Wallpaper
[ 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 than mechanical-to-read/write.
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 own data.
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 art. ]
AD's ASCII art of a single track in a ID-less recording format
sector sector sector sector ... [data] [data] [data] [servo] [data] ... ^ ^ | | gap gap
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" recording work.
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" with sector-servo.
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 capacity!
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