The following are examples of modern HD specifications. They happen to be for two of the three drives on my current systems, one a desktop unit (MAXTOR 6L040J2) and the other a notebook (IBM DJSA-220).

[2003.01.29 11:10:04 AM EST] I have added the specifications for the IBM (now Hitachi, I guess) Deskstar 180 GXP, a HD with 180GB capacity.
What I'd like to point out particularly, in the table showing the "zones" on that drive, is that each cylinder of zone 0 has a data capacity of 3,354,624 bytes. This means that, for this drive, the read/write heads only need to move after having read 3,354,624 bytes. Now this amounts to 6,552 sectors or 819 clusters at the standard NTFS allocation of 8 contiguous sectors per cluster. Assuming (and it is a big assumption) that NTFS will allocate a minimum of 8 clusters (64 sectors) whenever it allocates new space for a file (in order to attempt to maintain optimum 'track alignment'), then this zone's cylinders can each appear to have over 100 fragments, possibly even to 100 different files yet there will be 0 head movements required to access that data between each of those files! This presents a radically different situation than for HDs of even 3 years ago and older.
The information tables for the IBM Deskstar 180 GXP are at the bottom of this topic, after the tables describing the HDs that were the original inclusions for the topic. -- Jim Nelson

What is the nominal capacity (Gb or Mb) of these drives? (I know I could do the math based on the numbers given, but.... ;-)
The Maxtor is 40GB and the IBM is 20GB.
Maxtor manufactures the same drive in 20, 40, 60 and 80 GB, the only difference being the number of surfaces used. 20GB uses only one surface of the single platter. The 40 unit uses both surfaces of the single platter. The 60GB uses 3 surfaces of two platters and the 80GB uses all four surfaces of the two platters.
Had I known that before I bought, I would have bought the 80GB unit, only to get the benefit of having 4 tracks-worth of data stored before the heads had to be moved. -- Jim Nelson

What kind of software are you using to derive these data? Spec obviously doesn't say it. You're not considering slips.

	MAXTOR 6L040J2	IBM DJSA-220
Bytes per Sector	512	512
Data Zones (user)	15	16
Sectors per Track	481-882	293-560
Number of Platters	1	2
Tracks per Cylinder	2	4
Number of Cylinders	58,970	38,760
Total User Sectors	78,177,792	39,070,080
Seek Times (read)
Track to Track	.8	2.5
Average	8.5	12.0
Full Stroke	17.8	23.0
Latency	4.2	7.1
Buffer size (MB)	2	2
Rotational Speed (RPM)	7,200	4,200
Data Transfer Rates (Mbps)	236-472	109-203
Interface Transfer (MB/sec)	133.0	66.6

Following is the cylinder/sector distribution for the MAXTOR 6L040J2.
Note that for zones 1 - 15 (user data zones), zone 15 is the innermost and zone 1 the outermost. Also, zone 0 stores system data.

ZONE	CYLS	Sectors/Track	Data Rate
0	68	299	469.23
1	2582	837	551.28
2	4412	826	543.59
3	4123	814	536.20
4	3539	805	530.22
5	4068	789	520.51
6	4380	784	509.62
7	4388	744	489.88
8	5022	700	461.54
9	5199	658	434.62
10	4406	616	407.05
11	3332	588	387.96
12	3985	548	360.95
13	2933	522	344.62
14	2914	419	323.53
15	3696	457	304.20

Following is the cylinder/sector distribution for the IBM DJSA-220.

ZONE	CYLS	Sectors/Track
0	768	560
1	768	560
2	2046	533
3	1280	520
4	1024	506
5	1536	480
6	1536	480
7	1792	453
8	1280	440
9	1536	420
10	2048	400
11	1280	380
12	1792	360
13	1280	340
14	2048	320
15	768	293

IBM Deskstar 180 GXP, added Jan. 29, 2003

	IBM Deskstar 180GXP
Bytes per Sector	512
Data Zones (user)	27
Sectors per Track	536 – 1,092
Number of Platters	3
Tracks per Cylinder	6
Number of Cylinders	70,553
Total User Sectors	361,882,080
Total Data Bytes	185,283,624,960
Seek Times (read)
Track to Track	1.1
Average	8.5
Full Stroke	15.0
Latency	4.17
Buffer size (MB)	8
Rotational Speed (RPM)	7,200
Data Transfer Rates (Mbps)	Not available
Interface Transfer (MB/sec)	100.

The following table describes the zone allocations for the IBM Deskstar 180 GXP:

ZONE	CYLS	Sectors/Track	Bytes per Cyl.
0	1,152	1,092	3,354,624
1	4,480	1,071	3,290,112
2	3,591	1,050	3,225,600
3	3,483	1,050	3,225,600
4	3,771	1,008	3,096,576
5	2,031	997	3,062,784
6	3,384	980	3,010,560
7	1,916	966	2,967,552
8	3,421	945	2,903,040
9	1,969	924	2,838,528
10	3,116	910	2,795,520
11	2,458	892	2,740,224
12	3,817	861	2,644,992
13	2,349	840	2,580,480
14	2,235	840	2,580,480
15	3,116	798	2,451,456
16	937	787	2,417,664
17	2,807	770	2,365,440
18	856	756	2,322,432
19	3,067	735	2,257,920
20	3,059	700	2,150,400
21	2,235	672	2,064,384
22	1,839	651	1,999,872
23	2,752	630	1,935,360
24	2,298	588	1,806,336
25	2,534	560	1,720,320
26	1,827	536	1,646,592

---

Isn't this rather presumptious of how a lot of unknown processes work?
In reality NTFS doesn't allocate a load of empty clusters when you create a new file on the offchance that it will increase in size and all be in the same cylinder. Files inevitably end up fragmented all over the disc and therefore the heads will be moving about to read various bits. Cache size may well be more significant.
http://www.storagereview.com is the best website I know for hard drive information.

For most IDE drives the OS hasn't much of a clue about drive geometry because the BIOS translates it to an arbitrary Cylinder/Head/Sector address - claiming things like 255 physical heads etc.

---

contributors: Jim Nelson

---

Category Hardware