HDD Geometry Issues

jdow jdow at earthlink.net
Wed Jun 28 23:39:33 UTC 2006

From: "Sean M." <sigma_zk at yahoo.com>

> My HDD is an ST340810A 3.31. The BIOS gives its stats as:
> Cylinder:     19158
> Head:            16
> Precomp:          0
> Landing Zone: 19157
> Sector:         255
> I found the official doc at
> http://www.seagate.com/support/disc/specs/ata/st340810a.html although
> I'm not too sure how to interpret it.
> When I go to allocate disk space during install, it says that a
> geometry of 77545/16/63 is incorrect and uses instead 4865/255/63. Even
> when I reset the geometry to 19158/16/255, it says that's wrong too.
> If I use the entire disk with 'A', I see:
>  Offset  Size(ST)       End   Name  PType     Desc  Subtype
>       0        63        62   ---      12   unused     0
>      63  78156162  78156224  ad0s1      8  freebsd    165
> 78156225      9135  78165359   ---      12   unused     0

In real terms modern operating systems don't give a moldy Fig Newton
about the CHS specifications of the drive. They simply multiply the
numbers out and use absolute block numbers, instead. I do note that
the 4865/255/63 geometry is smaller than the BIOS geometry by a
little. The 77545/16/63 is 720 blocks bigger than the BIOS geometry.

Draw your own conclusions. Now, the question is "Precisely how many
BLOCKS are there on the disk?"

If FreeBSD insists on something smaller based on its own CSH algorithm
I'd be wondering why. In the bad old days of ST-506 drives this was
meaningful. The CHS values could be manipulated to speed up disks on
machines using these drives. But even the old Commodore 6502 based
machines and old Apple machines showed that there was no good reason
for the number of blocks per head per 360 degrees of the surface needs
to be constant. The ONLY thing that seems to be stuck in the old CSH
model are floppy disks for DOS type PCs. Hard disks use varying numbers
of blocks per track to increase capacity by keeping the bit density
roughly constant. CDs and DVDs carry this one more step and use a
spiral track.

With such variable track density disks no single CSH value is particularly
good for optimizing seeks. You must know the disk structure in detail
to work those optimizations. So it's easier to simply think in terms of
blocks and work from there.

All that said, if the BIOS total block count is not incredibly wrong
(landing zone WITHIN the recording area of the disk?) I'd wonder why
the FreeBSD tool would not accept its numbers. If the final numbers
you gave are real then all three sets of values should work. In any
case the total size lost from the largest to the smallest of those
CSH figures is a mere (by today's standards) 4677120 bytes, oddly
that's precisely what the figures you show. The Seagate site shows
the size is consonant with the 77545/16/63 number.

BUT note this from right at the bottom of the Seagate page you cite:
"Seagate reserves the right to change, without notice, product
offerings or specifications. (04/10/2001)"

They may have made a change. I wonder if there is a utility that will
return the actual capacity that the drive reports to the OS.

{^_^}   Joanne (Did SCSI drivers for the Amiga for quite a few years
        and watched the development of these techniques take place.)

More information about the freebsd-questions mailing list