From owner-freebsd-hackers Mon Jan 15 14:38:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA15471 for hackers-outgoing; Mon, 15 Jan 1996 14:38:04 -0800 (PST) Received: from lovely.spam.frisbee.net.au (spam.apana.org.au [202.0.75.1]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA15459 for ; Mon, 15 Jan 1996 14:37:50 -0800 (PST) Received: (from miff@localhost) by lovely.spam.frisbee.net.au (8.6.12/8.6.12) id JAA20677; Tue, 16 Jan 1996 09:17:52 +1030 Date: Tue, 16 Jan 1996 09:17:51 +1030 (CST) From: michael smith To: Bruce Evans cc: hackers@freebsd.org Subject: Re: location of bad144 table In-Reply-To: <199601151922.GAA06374@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk On Tue, 16 Jan 1996, Bruce Evans wrote: > In FreeBSD >2.0.5., the end of the disk (according to d_secperunit) is > used in all places (except in the bad144 man page :-(). This is > not fully compatible with the DEC standard 144, but the "last track" > is too slippery to use if the geometry is translated or the number > of sectors/track is variable. It would appear that the bad144 program still uses the 'c' partition, or divines the end of the disk in a fashion different from the kernel code. At least, bad144 runs without a slew of error messages, whilst attempting to read the disklabel once bad144 has been run results in much unhappiness. > Bruce Mike