Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!shodha.enet.dec.com!alan
From: alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.)
Newsgroups: comp.unix.ultrix
Subject: Re: Hard errors on device
Summary: icheck(8) and ncheck(8).
Message-ID: <3434@shodha.enet.dec.com>
Date: 21 Jun 91 02:01:54 GMT
References: <2841@calmasd.Prime.COM>
Distribution: usa
Organization: Digital Equipment Corp. - Colorado Springs, CO.
Lines: 41

In article <2841@calmasd.Prime.COM>, kjb@calmasd.Prime.COM (Ken Brucker) writes:
> I've got a disk that is failing on one of my Ultrix nodes.  What I'd like to
> know is if there's a way to determine which files have been corrupted by
> several bad block errors.  I've got the sn number, LBN and block number as
> reported by dump but don't know how to get to the file names from that info.

	First unmount the file system.  That way only failing hardware
	will change it.

	If the disk is failing as you watch, what you do next may not
	matter, except to look for the most recent backups.  Catastro-
	phic failures are an ugly sight.  If the disk is stable you
	may at this point want to replace any bad blocks that didn't
	get replaced, scan for more and on DSA disks clear the forced
	error flag.  See the manual page for rzdisk and radisk.

	Using the "sn" numbers use the -b option of icheck(8) to
	determine what part of the file system has been corrupted.
	In the case of files the -b option will tell you which inode 
	number.  You can use this with ncheck(8) to see which files 
	were corrupted.

	There's a fair chance that some of the corrupted blocks	
	are in the inode space of the file system which makes
	recovery much harder.  You may be able to use fsck to
	repair the damage, but it's a long process.

	On some versions of ULTRIX ncheck(8) may be very slow.  I
	don't know if the performance problems were ever fixed.
	Most other methods require mounting the file system, though
	dump records the inode number along with the file name.
	Searching through a verbose restore listing may be quick
	enough.  Others are using the -i option of ls(1) to get
	the inode number and the -inum option of find(1).
> 
> -- 
> ** Ken Brucker -- VMS Systems Programmer/Mangler -- ComputerVision


-- 
Alan Rollow				alan@nabeth.cxn.dec.com