From blocks to files (on a UNIXpc)

Peter Fales pfales at ttrde.UUCP
Fri Feb 10 06:06:43 AEST 1989


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.  Though I'm not sure what effect adding a
> bad block entry has on the freelist.

As it turns out, I am working on a program that does exactly this.  The
documentation I have is sketchy, but between knowing a little about UNIX
file systems, the information in /usr/include/sys/gdisk.h, and a little
experimenting, I was able to puzzle it out.  My program is a few weeks
(months?) away from being a useable product, but I can post it if there
is enough interest.

The way I am doing it - the only way so far as I know - is to search 
through the inode list, and look the list of blocks that belong to
each inode.  Then you can do a find -inum to find the file with that
inode.

There are a few other things to consider.  For example, the bad block
may be in the swap area, or (shudder) the inode list.  Actually, on
the unix-pc adding a bad block has no effect on disk space or on the free
list.  The file system normally uses only 16 sectors out of the 17
available on each track.  The 17th is used for sparing out other
sectors.   So, when you map out a bad block, it will be replaced transparently
by one of the spare sectors, with no change to the file system, but the 
data will be lost.  Hope you have good backups.

-- 
Peter Fales			AT&T, Room 2F-217
				200 Park Plaza
UUCP:	...att!ttrde!pfales	Naperville, IL 60566
Domain: pfales at ttrde.att.com	work:	(312) 416-5357		



More information about the Unix-pc.general mailing list