SUMMARY: Locating a filename from a block #

From: Matthew North (
Date: Wed Aug 03 1994 - 16:38:08 CDT


> I need some help with a disk that is producing media errors. We have been
> getting a intermittent media errors from a 1gb disk on an ELC
> running 4.1.3.

> The kernel helpfully reports the absolute block but when you run analyse
> on it, it doesn't show up. We have done the usual of changing the type of
> search and the block size. Sometimes this finds it other times it doesn't.
> If any of the blocks were found we repaired them through analyse.
> What I really would like to know, to see if there is some sort of pattern to
> these problems, is there a way of translating an absolute block # into
> a path / filename. The partition table holds the file system the block is in
> and each file is allocate a series of inodes, etc so if there a utility
> to do this for me automatically ?
> sd1h: Error for command 'read'
> sd1h: Error Level: Retryable
> sd1h: Block 407728, Absolute Block: 705818
> sd1h: Sense Key: Media Error
> sd1h: Vendor 'MICROP' error code: 0x11


You cannot use the absolute block number to get the filename but the relative block
number works a treat. Everyone suggested I use icheck and then ncheck. The command

icheck will take a relative block number for a file system and translate that into an
inode. Eg.

icheck -b 407728 /dev/rsd1c

comes backs with a line say the block bbbb relates to inode nnnn. icheck can fail according to
the manual if the superblock is corrupted very badly (hopefully not very likely !)

With the new found inode you run the command ncheck which will scan the file system looking
for the inode and then print the path.

ncheck -i 411652 /dev/rsd1c

In our case it turned out one of the swap file we use had the error. I have to say I was
suprised the system kept running. Needless to say we have remapped the block but still have
problems from time to time from elsewhere disk. I think basically the disk is getting to the
end of its useful life.

Some people suggested you use find ... -inum 411652 which can be faster on a mounted file
system but won't work if it isn't mounted.


There were about 20 people who replied to me and I would like to thank them. Unfortunately,
I can't list their names because I originally sent a summary about 3 days ago but to the wrong
address (I know what a twit) and then deleted their responses. Since I noticed nothing had
come out I have written it again :-)

Anyone who wants a step by step guide entitled "What File Has The Disc Error?" is welcome to a
copy that was sent to me. Just mail me and I will forward you a copy.

Thanks to all those that helped,

                              (. .)
Matthew North, Email:
X-Cel Communications, Ltd Phone: +44 1276 674025
1 Minster Court, Tuscam Way, Fax : +44 1276 674010
Camberley, Surrey, GU15 3YY
United Kingdom

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:07 CDT