From blocks to files (on a UNIXpc)

[Jim Rosenberg]

In article <462 at manta.pha.pa.us> brant at manta.pha.pa.us (Brant Cheikes) writes:
>Given a block number, how can I find out (a) if it's part of a file,
>and (b) what file it's part of?
>
>Why might this be useful?  Say you wake up one morning to discover a
>bad block error in your unix.log.  If you knew whether the block was
>allocated, and what file it was part of, you might be able to avoid
>having to reformat the disk.

This is something that people wanna do so often it amazes me there's not a
utility for this.  An fsdb wizard might be able to tell you how -- a script
redirecting fsdb's input???

At any rate, here's a method I've used on occasion when I knew I had a bad
block but had no idea what the file was.  You tar the entire file system to
/dev/null and capture the output.  There's a catch.  I'm not sure how it works
on the UNIX-PC's tar, but on some versions of tar the error message can VERY
EASILY escape notice.  E.g. you do something like

tar cvf /dev/null / >tar.list 2>&1

On some systems tar is too brain damaged to differentiate between EOF and a
read error, so a file with a bad block will show up as one *whose file size
changed*.  (tar reads fewer bytes than stat told it were there.)  So check
your capture for files whose size has changed.

One of the public domain tars may report file read errors unambiguously or
else if someone wants to do some quick hacking perhaps this could be hacked
into a PD tar without much work.  It would be much easier than doing it right
by writing a real utility that walks the file system reporting what blocks
belong to what files.  Quick & dirty, no warranty express or implied ... :-)
-- 
 Jim Rosenberg
     CIS: 71515,124                         decvax!idis! \
     WELL: jer                                   allegra! ---- pitt!amanue!jr
     BIX: jrosenberg                  uunet!cmcl2!cadre! /