Date: Thu, 1 Sep 2011 09:50:49 +0200 From: Polytropon <freebsd@edvax.de> To: Carl Johnson <carlj@peak.org> Cc: freebsd-questions@freebsd.org Subject: Re: Is there way to get filename for specific LBA? Message-ID: <20110901095049.6366dc8a.freebsd@edvax.de> In-Reply-To: <87vctc6hvp.fsf@oak.localnet> References: <201108311826.p7VIQRCY068730@mail.r-bonomi.com> <4e5f24c3.agV2UHzbjHEXght8%perryh@pluto.rain.com> <87vctc6hvp.fsf@oak.localnet>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 31 Aug 2011 20:50:18 -0700, Carl Johnson wrote: > perryh@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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110901095049.6366dc8a.freebsd>