Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!ogicse!milton!sumax!polari!rwing!fnx!del
From: del@fnx.UUCP (Dag Erik Lindberg)
Newsgroups: comp.unix.sysv386
Subject: Re: Mapping abs sector numbers to files
Message-ID: <1050@fnx.UUCP>
Date: 8 Jun 91 00:39:05 GMT
References: <767@dumbcat.sf.ca.us> <1991Jun06.123852.29851@virtech.uucp>
Organization: I/Ovations    Kirkland, WA
Lines: 39

In article <1991Jun06.123852.29851@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
>marc@dumbcat.sf.ca.us (Marco S Hyman) writes:
>
>>I haven't found this in TFM yet -- perhaps the net can help.  Given an error
>>message that says something like "SCSI absolute sector 1234 on drive 1 is bad"
>>how can I map this sector number to a file/directory/(inode!).  I've looked at
>
>Read mkpart(1M), specifically the -A flag.  Note that if you do add a bad
>sector, you should place an entry into /etc/partitions marking that sector
>as bad ("badsec =" - also documented on mkpart(1M)).

I don't think this is what was asked.  Marco wants to find out which *file*
is corrupt because of the bad sector.  And I can relate to his problem,
having had a similar problem on a customer machine.  Given the bad sector
error, it is trivial to 'mkpart' the sector into the bad sector list,
but how do you insure the file system is ok without restoring from a tape?

In the case I had to deal with, the customer did not have a current
backup of the system.  While I could make a backup of the system, there
were errors during the backup, and it was not clear from the output of
cpio which files were trashed, as the output of cpio is buffered
independently of stderr.  Someone advised me to mark the sectors as bad,
then fsck the drive, and fsck would report the truncated files.  Well,
it didn't, and then I was left with only a list of bad sectors.  I spent
a great deal of time getting that system fixed up.

Unless someone knows another method, the only thing I can think of for t
this situation is:
find / -print -exec cp {} /dev/null \;

which I have not tried.  I suspect it would only work if run from the
system console, and if the system console were a hardcopy device (or you
are extremely patient).  Note that trapping stderr from the find command
would not necessarily tell you anything, as the console error messages
are not going through stderr!

-- 
del AKA Erik Lindberg                             uunet!pilchuck!fnx!del
                          Who is John Galt?