From owner-freebsd-current Thu May 25 10:39:51 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id KAA02008 for current-outgoing; Thu, 25 May 1995 10:39:51 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id KAA02002 for ; Thu, 25 May 1995 10:39:49 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA20705; Thu, 25 May 95 11:32:52 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9505251732.AA20705@cs.weber.edu> Subject: Re: newfs weirdness... To: gene@starkhome.cs.sunysb.edu (Gene Stark) Date: Thu, 25 May 95 11:32:51 MDT Cc: blaise.ibp.fr!roberto@sbstark.cs.sunysb.edu, current@FreeBSD.org In-Reply-To: <199505250020.UAA09525@starkhome.cs.sunysb.edu> from "Gene Stark" at May 24, 95 08:20:32 pm X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@FreeBSD.org Precedence: bulk [ ... left for context ... ] > >> newfs doesn't seem to use the number of sectors by cylinder it gets > >> from the disklabel. It correctly warns that it will use 4096 and that > >> it differs from the disklabel value, though. > >> > >> Is that the expected behaviour ? > > > >Yes. Poul-Henning found that it was the best "geometry" to use with > >modern SCSI drives. Don't worry about it. > > Not everyone is using "modern SCSI drives" (some are even using IDE). > It is a constant annoyance to me that after I set up my IDE drive with > a particular geometry, newfs ignores it, prints a warning message, and > fails to utilize a bunch of odd sectors at the end of each partition. > > I have said this before, but I really would rather have newfs pay attention > to the geometry stated in the disklabel. If you want to format your > filesystems a different way, you can always set up your disktab or whatever. Actually, *especially* on IDE drives, you *don't* want to use the contents of the disklabel, unless the disklabel contains the real as well as the fictional geometry. It is just as pessimal to precompensate for a "seek" on an IDE drive based on a fictional (WRONG) geometry as it is to do so on a ZBR'ed SCSI device The FS *really*, *really* wants to use the real geometry for the device to let it do its optimization. To make both the BIOS and the UFS access happy, the geometry needs to be fictitious for the BIOS and real for UFS. And the slice drivers need to insure track boundries are observed. And because there is no other way to make it work, there has to be some mechanism of determining which drive in BIOS order is which drive in BSD order (I can go into great gory as to why this is confusing). Suffice it to say, your simple soloution... isn't. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.