Is there way to get filename for specific LBA?

Thu Sep 1 07:50:53 UTC 2011

On Wed, 31 Aug 2011 20:50:18 -0700, Carl Johnson wrote:
> perryh at pluto.rain.com writes:
> > One current userland utility (other than fsck) which does know
> > how to grovel through the metadata and index blocks is dump(8),
> > but you'd have to hack on it to report which inode was using a
> > particular block.
> 
> It looks like the best bet would be fsdb, assuming that it is a UFS
> file system.  That does have a 'findblk' command to find a file
> containing a block, but you would need to calculate the block offset in
> the filesystem first.  It doesn't look like it would be easy, as was
> said earlier.

Recently I had a similar problem with a disk (500GB SATA,
/dev/ad6 attached to controller ata3, one UFS data partition)
that had errors when accessing certain files or directories
like

	TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=419149408

or

	WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=9488927

Then also gvfs_done errors were displayed, and the disk then
magically disappeared.

On system startup, fsck failed:

	unknown: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=419149408
	ata3: timeout waiting to issue command
	ata3: error issuing READ_DMA48 command

There were

	CANNOT READ BLK: 419149408
	UNEXPECTED SOFT UPDATE INCONSISTENCY

and several more of such errors. The summary states:

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 419149408, 419149409, 419149410, 4
19149411, 419149412, 419149413, 419149414, 419149415, 419149416, 419149417, 4191
49418, 419149419, 419149420, 419149421, 419149422, 419149423, 419149424, 4191494
25, 419149426, 419149427, 419149428, 419149429, 419149430, 419149431, 419149432,
 419149433, 419149434, 419149435, 419149436, 419149437, 419149438, 419149439, 41
9149440, 419149441, 419149442, 419149443, 419149444, 419149445, 419149446, 41914
9447, 419149448, 419149449, 419149450, 419149451, 419149452, 419149453, 41914945
4, 419149455, 419149456, 419149457, 419149458, 419149459, 419149460, 419149461,
419149462, 419149463, 419149464, 419149465, 419149466, 419149467, 419149468, 419
149469, 419149470, 419149471, 419149472, 419149473, 419149474, 419149475, 419149
476, 419149477, 419149478, 419149479, 419149480, 419149481, 419149482, 419149483
, 419149484, 419149485, 419149486, 419149487, 419149488, 419149489, 419149490, 4
19149491, 419149492, 419149493, 419149494, 419149495, 419149496, 419149497, 4191
49498, 419149499, 419149500, 419149501, 419149502, 419149503, 419149504, 4191495
05, 419149506, 419149507, 419149508, 419149509, 419149510, 419149511, 419149512,
 419149513, 419149514, 419149515, 419149516, 419149517, 419149518, 419149519, 41
9149520, 419149521, 419149522, 419149523, 419149524, 419149525, 419149526, 41914
9527, 419149528, 419149529, 419149530, 419149531, 419149532, 419149533, 41914953
4, 419149535,

CANNOT READ BLK: 419525632
UNEXPECTED SOFT UPDATE INCONSISTENCY

THE FOLLOWING DISK SECTORS COULD NOT BE READ: 419525632, 419525633, 419525634, 4
19525635, 419525636, 419525637, 419525638, 419525639, 419525640, 419525641, 4195
25642, 419525643, 419525644, 419525645, 419525646, 419525647, 419525648, 4195256
49, 419525650, 419525651, 419525652, 419525653, 419525654, 419525655, 419525656,
 419525657, 419525658, 419525659, 419525660, 419525661, 419525662, 419525663,
CYLINDER GROUP 1115: BAD MAGIC NUMBER
UNEXPECTED SOFT UPDATE INCONSISTENCY

After that, fsck suggested to re-run the procedure because
the file system couldn't be marked clean. I just had a look
at the device files and...

# ll /dev/ad*
crw-r-----  1 root  operator    0, 108 Aug 23 01:40 /dev/ad4
crw-r-----  1 root  operator    0, 113 Aug 23 01:40 /dev/ad4s1
crw-r-----  1 root  operator    0, 116 Aug 23 03:40 /dev/ad4s1a
crw-r-----  1 root  operator    0, 117 Aug 23 01:40 /dev/ad4s1b
crw-r-----  1 root  operator    0, 118 Aug 23 03:40 /dev/ad4s1d
crw-r-----  1 root  operator    0, 119 Aug 23 03:40 /dev/ad4s1e
crw-r-----  1 root  operator    0, 120 Aug 23 03:40 /dev/ad4s1f
crw-r-----  1 root  operator    0, 121 Aug 23 03:40 /dev/ad4s1g
crw-r-----  1 root  operator    0, 122 Aug 23 03:40 /dev/ad4s1h

Tadaa! You see: /dev/ad6 isn't _there_ anymore!

I rebooted the system, skipped _any_ checks of /dev/ad6 and
carefully mounted it (being given the correct warning):

	# mount -t ufs -o ro /dev/ad6 /mnt

I could then browse the disk, but when entering some directories,
error messaged (as above) did show up again. Then the disk was
empty, and finally it was gone.

As I had the original data on another disk, it wasn't a data
loss for me, but a very interesting behaviour of a disk!

When browsing the disk with the Midnight Commander, many files
were size 0, prefixed with !, and colored red. This indicates
that they couldn't be stat()ed. This traditionally shows that
the file system is damaged. A dying disk could be the reason.
But malfunctioning controllers and software errors also could
be, even though it's often the _disk_ that needs replacing.

With this introduction, I would give the following suggestion:

Damaged files often cannot be "detected" by a stat() call. A
means to _try_ to "detect" all files is to tar them. Mount the
disk, use -o ro for security, and then run:

	# tar cvf /dev/null /mnt/

where /mnt is where you have mounted the disk in question. The
tar program should now try to read all the files. Those that
it cannot read (see stderr output) are to be considered damaged.
Then locate those files. Use

	# ls -i <filename>

This information can be used for the fsdb program. In case you're
working on a mounted partition, use

	# fsdb -r <device>

in order to find out more about the files (inodes) that you suspect
being damaged.

Also see "The Sleuth Kit" (port "sleuth") with the ils and fls tools
that can give good information about files and inodes.

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...