Date: Tue, 28 Nov 95 22:17 WET From: uhclem%nemesis@fw.ast.com To: FreeBSD-gnats-submit@freebsd.org Subject: misc/848: Inst gripes about geometry but won't accept true values FDIV040 Message-ID: <m0tKdxR-000CQlC@nemesis.lonestar.org> Resent-Message-ID: <199511290530.VAA12129@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 848 >Category: misc >Synopsis: Inst gripes about geometry but won't accept true values FDIV040 >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Nov 28 21:30:03 PST 1995 >Last-Modified: >Originator: Frank Durda IV >Organization: That costs extra >Release: FreeBSD 2.1-STABLE i386 >Environment: 2.1.0-RELEASE (or STABLE?) System consists of a 540Meg IDE and 2.0GB SCSI. Boots from IDE. SCSI Adapter is a Adaptec 1540B, latest firmware and microcode. BIOS boots from the IDE and has no CMOS settings for the SCSI devices. >Description: 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 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. 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. 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. >How-To-Repeat: Try to set the settings to the true dimensions of a drive where these are different than the %d/64/32 that the partition program seems to be stuck on. >Fix: Choose: 1. Fix the partition software (also disklabel utility) to accept the real values for that drive. 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. If input to the "G" command can't be accepted even when it is valid, you might as well pull the command. or 3. Both 1 and 2. This step in the installation could really throw a lot of people trying to install for the first time, and it only seems to do this to people with SCSI drives, which are supposed to be the drives of choice for FreeBSD. We need to make this more friendly in a big way. *END* >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0tKdxR-000CQlC>