Corrupted Filesystem * IDEAS *

[John C. Archambeau]

rick at crash.cts.com (Rick Stout) writes:
>In article <2527 at crash.cts.com> jca at pnet01.cts.com (John C. Archambeau) writes:
>>rick at crash.cts.com (Rick Stout) writes:
>>>In article <3295 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
>>>>>I've yet to see a disk drive without a second superblock at 16 (/etc/fsck -b16)
>>>>
>>>>I've seen plenty of them.
>>>>
>>>>Some of them were running the BSD file system; they had it at 32, not 16.
>>>
>>>Whats the purpose of a second superblock?
>>>If the first one is corrupted can you boot off the second?
>>
>>Or if a bad spot manifests itself at the first superblock.
>> 
>So how do you boot off the second superblock?
>
>Do you have to boot off a boot and root floppy, mount the
>hard disk and recover the superblock somehow?

Depends on how bad the superblock is damaged.  If you get a disk write error
during a sync, then the primary superblock has manifested a bad spot, but if
your file system supports backup superblocks, then the writes to the
subsequent superblocks will be ok, just that the write to the first superblock
didn't take so you're going to have to start reading from the backup
superblocks.

If your root file system has the the bad superblock and reading the backup
superblock(s) just doesn't help.  I am sorry to say that your root file system
is gone.  But if you are smart in laying on your file systems, the only thing
you should have in your root file system should be those things that you can
reload off of your distribution master tape or disk.  You could try dinking
with a file system debugger, but that can be messy business and sometimes can
make matters worse.  Someone suggested doing a dd of your superblock every
night.  Now that actually is a good idea because if your superblock is blown
away, you are going to have some serious problems.

You can try booting from floppy in single user mode and do an fsck and set the
option to read the backup superblock(s) instead of the primary.  If that
works, you're in business.  Backup your file system with the bad superblock
and do a surface analysis of the file system immediately.  If you have a bad
spot, better let Xenix know about it.

Unfortunately, I'm not well versed in Xenix file system specifics.  I'm
relaying my knowledge of the BSD 4.2 file system since I support Sun
workstations.  I am getting more well versed with SCO Xenix, but it has been
a problem setting aside time just to pick up Xenix specifics since it's not
really System V or BSD 4.2, it's to some degree in the middle from my (little)
understanding.

I just started with Xenix about a month ago and I'm still trying to get the
can and can nots down.
 
     // JCA

 /*
 **--------------------------------------------------------------------------*
 ** Flames  : /dev/null                     | Xenix is the ONLY thing
 ** ARPANET : crash!pnet01!jca at nosc.mil     | Microsoft did right.
 ** INTERNET: jca at pnet01.cts.com
 ** UUCP    : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
 **--------------------------------------------------------------------------*
 */