This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--1461724475-1728427609-859710151=:26381
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.NEB.3.93.970330001541.26381c@gnostic.cynic.net>

On 30 Mar 1997, Johan Danielsson wrote:

> SCSI 1 goes kaput, which causes a panic. The system reboots and then
> magically SCSI 2 will be sd1, and fsck has a nice opportunity to mess
> things up bad.
> 
> If I don't remember wrong, this did happen with some version of 4.3
> which had static geometry information, `gee, this is sd1, and I know
> it's *this* big', so you always had an extra lost disk, if you weren't
> quick enough.

We don't use compiled-in geometry information anymore, and the
disklabel now has filesystem information for each partition. If
fsck_ffs will even think about attempting to work on a partition
that isn't marked `4.2BSD', it's rather broken, and fixing that is
the correct solution.

Yes, I suppose you could have a disk where the disklabel section
just happens to checksum just like a BSD disklabel, and it might
just happen to have what appears to be partition information and
a 4.2BSD parition in it that matches one from the dead disk (so it
appears in /etc/fstab), and it could look like such a lightly
damaged FFS filesystem that fsck tries to fix it, rather than just
choking completely. Just possibly, I suppose.

cjs

Curt Sampson    cjs@portal.ca		Info at http://www.portal.ca/
Internet Portal Services, Inc.		`And malt does more than Milton can
Vancouver, BC   (604) 257-9400		 To justify God's ways to man.' 

--1461724475-1728427609-859710151=:26381--