Date: Wed, 28 Jun 2006 16:39:26 -0700 From: "jdow" <jdow@earthlink.net> To: <freebsd-questions@freebsd.org> Subject: Re: HDD Geometry Issues Message-ID: <0a5e01c69b0c$182b6dd0$0225a8c0@Wednesday> References: <20060628215928.35227.qmail@web52306.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "Sean M." <sigma_zk@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.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0a5e01c69b0c$182b6dd0$0225a8c0>