Subject: Re: Dynamic SCSI ids (was: A possible way of handling...)
To: Johan Danielsson <email@example.com>
From: Curt Sampson <firstname.lastname@example.org>
Date: 03/30/1997 00:22:31
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 email@example.com for more info.
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
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.
Curt Sampson firstname.lastname@example.org 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.'