From owner-freebsd-hackers Tue Jan 24 12:34:48 1995 Return-Path: hackers-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id MAA10629 for hackers-outgoing; Tue, 24 Jan 1995 12:34:48 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id MAA10613 for ; Tue, 24 Jan 1995 12:34:45 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA13725; Tue, 24 Jan 95 13:28:41 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9501242028.AA13725@cs.weber.edu> Subject: Re: disklabel (1.1.5.1), partitions To: phk@ref.tfs.com (Poul-Henning Kamp) Date: Tue, 24 Jan 95 13:28:41 MST Cc: bde@zeta.org.au, freebsd-hackers@freefall.cdrom.com, kuku@gilberto.physik.rwth-aachen.de In-Reply-To: <199501241823.KAA21387@ref.tfs.com> from "Poul-Henning Kamp" at Jan 24, 95 10:22:58 am X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > > > > Hold on! How about because the kernel should know the real BIOS apparent > > > > geometry for instead of making things up like that? > > > true, except we cannot trust this one anymore :-( Some IDE and SCSI > > > drivers get their "geometry" in CONFIG.SYS these days. > > > > Actually, most EIDE controllers get them from a modified system boot block > > installed by the OEM for the machine. Blowing the system boot block in > > that case really screws you up. > No, 540Mb and above seems to get it from various "disk-managers" loaded > in the config.sys with an increasingly annoying frequency. I lost this article. 8-(. I think it was in comp.os.386bsd.developer. Specifically, it referenced the Gateway boot code installing an INT 13 redirector. I can't remember who wrote it ("Vince" sounds familiar, though). > > I don't understand... what's wrong with: > > > > Geometry CCCC/HH/SS (Physical CCCC/HH/SS) > The Physical isn't true, It's two years since I saw anything which added > (multiplied actually) up to the number of sectors available. > The numbers are fiction, make belive, has no use, value or connection > with our use of the drive. I typically *use* the the physical geometry, particularly if there are more than 1024 cylinders. Specifically, C cylinders C' translated cylinders H heads H' translated heads S sectors S' translates sectors Why? Because I will never be provided with a translated number of cylinders that exceed 1024. Because of this, if the translation is not sufficient for BIOS to be able to use the whole disk, I'd rather not give that space away under BSD as well, thank you. Using an AHA1742 in advanced translation mode with a Maxtor Panther drive yields an additional .7G of disk this way. Just as an example. I can give the actual calculation steps, if I need to. They are in the archives of this list, already, however. > > > Has nothing to do with it. If you pass some of the weird geometries to > > > newfs it will become very confused... 32/64 works sensibly most of the > > > time. > > > > This is a bug in newfs, like the one where it doesn't create a lost+found, > > not a reason to bogify other parts of the system to hack around it. > Not true. I don't understand. Are you saying that it's OK for newfs to become confused, it's OK to not create lost+found, or both? >Newfs and UFS was optimized to know about disk-geometry. Since > most (95%) drives these days are zoned (variable sectors/track), this isn't > of any particular use. The existense of caches on the drives doesn't improve > it either. > All the geometry is really used for is to size the "cylinder"-groups. It's not of any particular use, unless the translated geometry limits the addressable space on the disk to less than the actual space on the disk. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.