Very Computer

Hi All,

I have an RS6K model 7006 that is running AIX 4.2.1. Something has
damaged files
on one filesystem in such a way that any attempt to access them in any
way causes a crash: flashing 888 - 102 - 700 - 0c0. This includes the
commands rm -rf, ls, acledit, tar and others. Even fsck run on the
quiescent (unmounted filesystem) fails - it issues the following
messages and simply exits.

** Checking  /dev/rlv01 (/home)
** Phase 0 - Check Log
log redo processing for /dev/rlv01
** Phase 1 - Check Blocks and Sizes
Unknown File Type I=41088 owner=1827866635 mode=36635053170 size=

(At which point fsck exits)

I would prefer to fix the filesystem if possible rather than deleting
the filesystem/logical volume, recreating the filesystem and restoring
from last weeks backups (assuming that process would work). Almost all
the files are apparently still accessible - there appear to be a small
number of files that cause the error noted above. I have run stand-alone
diagnostics on the computer including the SCSI bus as well as the disks
(including a surface verify) which seem to minimize the possibility of a
hardware fault.

Any ideas or suggestions would be most appreciated. Are there any tools
available to manually repair the inode map/entries? Even deleting these
files/directories that are causing the errors would be fine.

Thanks,

David

One way would be to upgrade the OS - I know that, at one time, a lot of
work was put into hardening JFS against corrupt filesystems. This was
probably the number one reason for system crashes a couple of years ago.
I don't remember if this was pre- or post 4.2.1 though...

Maybe even the latest 4.2.1 JFS fixes will do the trick.

If it's not a rootvg filesystem, you can even import the volume group on
another box running a later version of AIX and try fsck from there.
Don't try that with a rootvg though...

Quote:

> I have run stand-alone
> diagnostics on the computer including the SCSI bus as well as the disks
> (including a surface verify) which seem to minimize the possibility of a
> hardware fault.

This is, as you suggest, most likely _not_ a hardware problem.

Quote:

> Are there any tools available to manually repair the inode map/entries?
> Even deleting these files/directories that are causing the errors would be fine.

You can try fsdb, the filesystem de*. However, it requires you to
know a lot of the internal structure of the filesystem.

If you have located the offending files, you can of course make a fresh
backup of the filesystem, beeing careful to avoid any damaged files, and
then rebuild it from that backup.

--
Christer Palm