Re: HDD Geometry Issues
- From: "jdow" <jdow@xxxxxxxxxxxxx>
- Date: Wed, 28 Jun 2006 16:39:26 -0700
From: "Sean M." <sigma_zk@xxxxxxxxx>
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.)
_______________________________________________
freebsd-questions@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"
- References:
- HDD Geometry Issues
- From: Sean M.
- HDD Geometry Issues
- Prev by Date: Re: Are hardware vendors starting to bail on FreeBSD ... ?
- Next by Date: Raid card for FreeBSD
- Previous by thread: HDD Geometry Issues
- Next by thread: HDD Geometry Issues
- Index(es):
Relevant Pages
|
|
