From owner-freebsd-hackers  Mon Jan 15 11:24:48 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id LAA01955
          for hackers-outgoing; Mon, 15 Jan 1996 11:24:48 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA01948
          for <hackers@FreeBSD.org>; Mon, 15 Jan 1996 11:24:44 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id GAA06374; Tue, 16 Jan 1996 06:22:50 +1100
Date: Tue, 16 Jan 1996 06:22:50 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199601151922.GAA06374@godzilla.zeta.org.au>
To: hackers@FreeBSD.org, miff@spam.frisbee.net.au
Subject: Re: location of bad144 table
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

>- The calculation above could be modified to check the 'c' partition on the
>disk first.  This would facilitate using the sizing of the 'c' partition
>to lie about the size of the disk (what I was trying before).  NOTE: this
>is consistent with the way that the bad144 program operates; I was quite
>fooled by its success 8(.

Don't do that!  :-)  In FreeBSD-1.1, bad144 put the bad sector
information (not the sectors) "in the first 5 even numbered sectors of
the last track of the disk pack", but various parts of the kernel and
drivers got the bad sector information from the end of the disk
(according to d_secperunit) less one track, or from the end of the disk
(according to the size of the `c' partition) less one track.  This was
confusing when the 3 places were different.

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.

Bruce