From: Lori Anderson (lori.anderson@alcatel.com)
Date: Tue Apr 09 2002 - 18:42:19 EDT
Hello All!
I am having a common problem but a question I can not seem to locate an
answer to. I hope to find one from someone here.
In the simplist terms to explain I am trying to determine a method of
seeking out a corrupted filesystem before a reboot. An application
upgrade corrupted our system and it appears okay until we attempted to
do a system backup and a local primary system backup to an alternate
system drive. But once we reboot the system and fsck'd the system drive
the system is okay.
We want to determine if any inodes or superblocks are corrupt before
doing a backup only then to find out that it is in a bad state. Nor do
we want to fsck the system disk to resolve the problem. And we certainly
do not want to fsck the system disk while the filesystems are mounted as
recommended. We have been looking at fsdb, clri, fsdb_ufs, ncheck but
nothing has really helped us and that is in part due to our lack of
knowledge in these utilities.
Ufsdump logs informed us that we have corrupted inodes. This is an error
from the ufsdump log:
expected next file 231172, got 225931
The script failed to backup to the alternate drive due to these errors.
Before the app upgrade the script worked fine. We know that the
application somehow corrupted the inodes. By using ncheck in conjunction
w/ the ufsdump log we believe we found the particular inodes which have
been corrupted by this application upgrade.
These are the inodes that ufsdump is complaining about on
auds770:
expected next file 727006, got 727005
cannot find directory inode 297440
These are the filenames for these inodes:
auds770# ncheck -F ufs -a /dev/rdsk/c0t0d0s0 | egrep -e
'(727006|297440)'
297440 /lost+found/#710165/nls/mesg/./.
297440 /lost+found/#710165/nls/mesg/.
727006 /etc/lib/ld.so.1
Here's the inodes another system is complaining about:
auds771# ncheck -F ufs -a /dev/rdsk/c0t0d0s0 | egrep -e
'(304927|120212|269569)'
120212 ???/lost+found/./.
120212 ???/lost+found/nls/../.
269569 /usr/lib/locale/en_CA/LC_CTYPE/mb.so.1
304927
/opt/pkgs/NetID422_1083/SOLARIS/packages/NID42apsv/reloc/$INST/images/Ab
outBox.gif
Our question remains is how without a ufsdump log or a reboot or fsck
do we determine if our system inodes/blocks/filesystems have been
corrupted?
We have placed the latest patch cluster on the system 105181-31 and
retested with the same corruption results. And this is a test
environment att.
Thank you for the time taken for Reading and Responding!
Lori
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:24:11 EDT