Date: Wed, 29 Nov 1995 21:58:02 +1100 From: Bruce Evans <bde@zeta.org.au> To: hackers@freebsd.org, uhclem%nemesis@fw.ast.com Subject: Re: misc/848: Inst gripes about geometry but won't accept true values FDIV040 Message-ID: <199511291058.VAA17247@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>During the installation, the SCSI drive was partitioned. >The partition software complains that the geometry is not correct >and that it should be corrected or terrible things will happen. >Using the "G" command, the correct values are entered, ie 2707 cylinders, >19 heads, 81 sectors (per manufacturers data sheet for a Seagate ST12550N). >After the data is entered, the partition software again says that the >geometry is not correct and the same values that were there before >reappear (2039/64/32), along with messages warning of woe and disaster These are not correct values. You're supposed to enter the values used by the BIOS, not the physical values. The BIOS requires the geometry to satisfy the following constraints: 1 <= sectors <= 63 1 <= heads <= 256 1 <= cylinders <= 1024 sysinstall apparently enforces this, unlike fdisk which silently screws up. There may be additional constraints. E.g., for wd drives and old BIOSes: heads <= 16 For BT445C and perhaps other SCSI BIOSes: heads >= 255 More importantly: ****************************************************************** if the BIOS was previously configured to use S sectors and H heads for the drive, and sysinstall gets the defaults for these wrong (whether or not it warns you), then you must tell sysinstall that the drive has precisely S sectors and H heads (whether or not the manufacturers data sheet agrees or sysinstall warned you). ****************************************************************** Modern drives usually have (an average of) more than 63 sectors/track so copying the number of sectors from (the wrong section of?) the manufacturers data sheet is unlikely to work. >somewhere down the road should you not use the "G"eometry command to set >the correct values. Trying again gets you the same result and the data >you enter is discarded. Perhaps the original 64/32 geometry was correct. sysinstall should allow you to use it. More than 63 sectors is certainly incorrect, so sysinstall doesn't allow it under any circumstances. >Interestingly, the internally computed values 2039x64x32 equal 4,175,872 >blocks, which is greater than 2707x19x81==4,166,073. This looks (on >the surface) like a really bad thing, as we may have computed a block count >greater than the true size of the media, and then later the system will >attempt to write who-knows-what out there. In the case of this particular >drive, the 81 sectors per track is the average rounded-down (according to >the data sheet), so there is some slop and the true user sector count was >4,177,781 so even the "bogus" numbers still work. The driver knows the exact number of sectors. After it determines the translated BIOS geometry of 64 heads and 32 sectors, it divides the total number of sectors by 64*32 and rounds down to obtain the translated number of cylinders. Note that about 2000 sectors are still wasted if you restrict yourself to the rounded-down number of cylinders. You avoid this wastage if the software permits. Just enter sector counts and ignore the bogus C/H/S values wherever possible. I'm not sure if sysinstall allows this. fdisk, disklabel, newfs and drivers do. >In reality, I suspect the drive returns the true block count and >it is divided against the hardwired 64 and 32, yielding 2039 as the >closest number that fits. It would be nice if the user could give the >system the vendor recommended numbers, particularly when the software >currently encourages the user to do this. On some types of drives, the >user could end up with less usable space on the drive because of these >hardwired values. I got lucky. It would be nice if the vendor could recommend non-bogus non-wasteful values. This is a hard problem for vendors because C/H/S values are inherently bogus and some BIOSes may not support all values. Note that the manufacturers data sheet suggests wasting considerably more space than for the bogus 64x32 geometry (all of cylinders 2707-2713 (4177781/19/81 = 2714)). This is a consequence of rounding the average number of sectors down to 81. Sector counts are low relative to cylinder counts so the wastage may be high (up to 1 in 82 compared with up to 1 in 2048 for your drive). >Choose: > 1. Fix the partition software (also disklabel utility) to accept > the real values for that drive. Perhaps there should be a separate option to specify and use the "real" values for the drive. However, hackers should have no problems running disklabel to specify the values and `newfs -u 0' to use them, not to mention knowing when this makes a difference. >or 2. Change the warnings to say the system is substituting these values > and they are close and might give you a bit more space or might > give you less, and everything will be fine, rather than implying > that something bad will happen if you can't cram the real settings > into the software (which apparently you can't). It would > also be nice if the system explained what magical hat these various > numbers (64 & 32) were being pulled from as well. They are determined by looking at the partition table: 64 = 1 + (max ending head number in a partition table entry) 32 = max ending sector number in a partition table entry If there are no partition table entries, then they are as reported by the drive (e.g., 2707/19/81). They are rarely right in this case. At least, disklabel would report these numbers. Perhaps sysinstall does some conversions since it knows that 81 sectors can't work. Some SCSI BIOSes also determine the numbers by peeking at the partition table. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511291058.VAA17247>