Choosing drive geometry (it's all lies anyway)

[Kevin O'Gorman]

I would appreciate comment on the following:

I don't know the underlying standards and protocols, but it has
appeared to me for some time that drive controllers lie to you about
drive geometry, and allow you to manipulate the lies to a certain
extent.  By that I mean that drives usually present themselves as
having 63 sectors and 255 heads although a cursory inspection
indicates, among other things, that those drives actually have exactly
1 platter and 2 heads.  It's hard to tell how many sectors, or if
that's even uniform across the disk surface.

I have found drives from the same manufacturer and vendor with
different apparent geometries, resulting in slightly different
capacities.  For example, I have three 2 TB Seagate hard drives.  Two
arrived set to 81 heads and 63 sectors, but another came configured
for 255 heads and 63 sectors.  The 81-head arrangement had a slightly
larger capacity.  It appears to me that 251 heads would yield even
(slightly) more.

Here's how it looks in fdisk for 81 heads:

> root at treat:/2tg# fdisk /dev/sdb
>
> WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
>          switch off the mode (command 'c') and change display units to
>          sectors (command 'u').
>
> Command (m for help): p
>
> Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
> 81 heads, 63 sectors/track, 765633 cylinders
> Units = cylinders of 5103 * 512 = 2612736 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x000ceacb
>
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sdb1               1      765634  1953513560   83  Linux
>
> Command (m for help): x
>
> Expert command (m for help): p
>
> Disk /dev/sdb: 81 heads, 63 sectors, 765633 cylinders
>
> Nr AF  Hd Sec  Cyl  Hd Sec  Cyl     Start      Size ID
>  1 00  32  33    0  80  63  513       2048 3907027120 83
>  2 00   0   0    0   0   0    0          0          0 00
>  3 00   0   0    0   0   0    0          0          0 00
>  4 00   0   0    0   0   0    0          0          0 00
>
> Expert command (m for help): q
>
> root at treat:/2tg# exit

So, to summarize, the drive shows 2000398934016 bytes, which is
3907029168 sectors of 512 bytes.
There's a maximum of 255 heads and 63 sectors allowed by the way MSDOS
partition tables are written.  (I'm only familiar with those, and
don't know the consequence of using other arrangements)
The main difference among the approaches that I'm showing is the
number of heads.  These three are the ones I've considered so far
255 heads and 63 sectors allows 243201 cylinders (16065 sectors each)
and a total of 3907024065 sectors
81 heads and 63 sectors allows 765633 cylinders (5103 sectors each)
and a total of 3907025199 sectors (1134 more)
251 heads and 63 sectors allows 247077 cylinders (15813 sectors each)
and a total of 3907028601 sectors (3402 more than 81 heads, and 4536
more than 255 heads)

As you can see from the above fdisk output, partitioning seems to
throw away 2048 sectors off the bat (a cylinder is 15813 sectors in
this scheme, so I'm a bit puzzled why it's so large -- it's not even a
multiple of the track size).

A long long time ago, as I recall, when the block size was bigger than
a sector, the blocks were not split across tracks, so with 63 sectors,
there was at least one "spare" per track, and this was used by the
bad-block software as needed.  Nowadays, these drives use SMART and do
their own reassignment.  I wonder if these sectors are still left
spare, in which case 62 or 60 might be a better choice of track size.

The choice of 251 heads and 63 sectors is going to be hard to improve
for these drives unless there are "spare" sectors to be reclaimed, or
there's some advantage to having smaller cylinders.  In this
arrangement, all but 567 sectors are incorporated into the formatted
drive (3907029168 - 3907028601 = 567)

By the way, to arrive at this arrangement, I just assumed 63 sectors
per track, making for 62016336 tracks, and used the factor(1) command
to find the largest size that allowed for a divisor near to 255.  This
came up pretty soon, with a count of 62016327 tracks, just off by 9
tracks.

Of course, all of this is quibbling about a small fraction of a
percent of the drive.  However, I go back to the days of counting
cycles, using 2-digit years, actual magnetic cores for memory, and
squeezing every resource hard, just to get things to fit.  It's hard
to change.  It bugs me to see the same drives with different
capacities.  This all started when "df -h" showed one drive as 1.9TiB
and the other as 1.8TiB.  Grrrrr.

--
Kevin O'Gorman, PhD