Re: fixing a bad sector

[mlelstv%serpens.de@localhost (Michael van Elst)]

gdt%lexort.com@localhost (Greg Troxel) writes:

>As to how to find which file the block is in, there were programs ncheck
>and icheck in the old days (sixth and seventh edition sometime).  It
>looks like fsdb will do this.

fsdb lets you find the inode that owns a disk block. You can use find
to search the directory entry that points to the inode.

For both tasks parts of the disk need to be readable and if possible,
it's a good idea to do this on a block copy (created with dd or similar).

Here is an example how to use fsdb to look up blocks used by a file
and then to search these blocks to find the file again.

% fsdb -n -f /dev/rdk3
** /dev/rdk3 (NO WRITE)
** File system is journaled; replaying journal
Editing file system `/dev/rdk3'
Last Mounted on /
current inode: directory
I=2 MODE=40755 SIZE=512
        MTIME=Sep  4 05:46:07 2017 [619673738 nsec]
        CTIME=Sep  4 05:46:07 2017 [619673738 nsec]
        ATIME=Sep  7 03:18:49 2017 [144962222 nsec]
OWNER=root GRP=wheel LINKCNT=24 FLAGS=0x0 BLKCNT=0x2 GEN=0x1693439e
fsdb (inum: 2)> lookup /bin/ls
component `bin': current inode: directory
I=18816 MODE=40755 SIZE=1024
        MTIME=Jul  9 01:37:53 2017 [0 nsec]
        CTIME=Jul  9 10:23:40 2017 [510918650 nsec]
        ATIME=Sep  7 07:51:10 2017 [172609721 nsec]
OWNER=root GRP=wheel LINKCNT=2 FLAGS=0x0 BLKCNT=0x2 GEN=0x13fa79ef
component `ls': current inode: regular file
I=18871 MODE=100555 SIZE=31984
        MTIME=Jul  9 01:37:52 2017 [0 nsec]
        CTIME=Jul  9 10:23:22 2017 [226922183 nsec]
        ATIME=Sep  7 03:18:51 2017 [235554496 nsec]
OWNER=root GRP=wheel LINKCNT=1 FLAGS=0x0 BLKCNT=0x40 GEN=0x4dcaf7cf
fsdb (inum: 18871)> blks
I=18871 64 blocks
Direct blocks:
0: 82784 83288 83664 83672 
fsdb (inum: 18871)> findblk 82784
fsdb (inum: 18871)> findblk 165568
165568: data block of inode 18871
fsdb (inum: 18871)> print
current inode: regular file
I=18871 MODE=100555 SIZE=31984
        MTIME=Jul  9 01:37:52 2017 [0 nsec]
        CTIME=Jul  9 10:23:22 2017 [226922183 nsec]
        ATIME=Sep  7 03:18:51 2017 [235554496 nsec]
OWNER=root GRP=wheel LINKCNT=1 FLAGS=0x0 BLKCNT=0x40 GEN=0x4dcaf7cf


The first attempt to 'findblk' didn't show anything. This is because the
blks command reports different kind of blocks than findblk accepts.

blks -> a block is a relative fragment address. This filesystem uses
1024 byte fragments (and 8192 byte "blocks").

findblk -> a block is a relative logical disk address. This disk uses 512 byte
logical blocks, which is taken from the filesystem superblock. So to search
for the first "fragment address" I needed to double the value.

The kernel disk driver reports errors as 'fsbn' using 512byte units.
If your disk has 512byte logical blocks, you can pass the fsbn number
to findblk. Most disks, even "4k sector" disks use 512byte logical blocks.

You can look at the superblock of a filesystem with 'dumpfs -s'. The relevant
values are:
'fsize' -> fragment size in bytes
'fsbtodb' -> number of bits to shift fsize to get the logical disk block size. E.g. with fsize=1024 and fsbtodb=1 the disk blocks are 1024 >> 1 = 512 bytes.

All these different addresses are 'relative' to the partition start, so
the partition offsets can be ignored.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."