[mythtv-users] Need help with tracing bad disk blocks on JFS disk to file(s)
Craig Huff
huffcslists at gmail.com
Thu Jan 24 17:05:52 UTC 2013
Recent testing with smartmon revealed that one of my recordings disks is
showing some bad blocks. I wanted to find the file(s) affected and move
them to another disk so I can do something to cause the bad blocks to get
replaced by spares. My problem is that the HOWTOs I found deal with EXT2/3
formatted partitions and I haven't been able to figure out how to duplicate
the process for tracing block numbers to file(s). Here's what I have so
far been able to do:
1) Identify bad blocks:
# smartctl -l selftest /dev/sde
smartctl version 5.38 [i686-pc-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining
LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed: read failure 90% 10571
1084296743
This shows at least one bad block, 1084296743, present on the disk.
2) Got data on disk partition:
# fdisk -lu /dev/sde
Disk /dev/sde: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000db3e7
Device Boot Start End Blocks Id System
/dev/sde1 63 1953520064 976760001 83 Linux
This shows that the first block in the partition is block 64 on the disk.
3) Identify partition mountpoint:
# df -h|grep sde
/dev/sde1 932G 838G 95G 90% /video3
This shows that /dev/sde1 is mounted as /video3.
4) Identify formatting of the partition:
# grep video3 /etc/fstab
# /video3 was on /dev/sdd1 during installation
UUID=d8fb0131-65d1-482e-9afb-
c0189353b84b /video3 jfs
defaults 0 2
This shows that the partition is a JFS partition, not an EXT2/3 partition
(nor anything else, for that matter).
5) Test for blocks that report problems near the one of interest:
# i=1084296730
# while [ $i -lt 1084296750 ]; do
> echo $i
> dd if=/dev/sde of=/dev/null bs=512 count=1 skip=$i
> let i+=1
> done
...snip...
1084296736
dd: reading `/dev/sde': Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 28.6135 s, 0.0 kB/s
...snip
This shows that blocks 1084296736 thru 1084296831 have problems.
6) Calculate the first logical JFS block using this formula:
(First Bad Physical Block - First Partition Physical Block) * Bytes per
Block / Bytes per Partition Logical Block
# expr 1084296736 - 63
1084296673
# expr 1084296673 \* 512 / 4096
135537084
This shows that the first logical block affected is block 135537084.
7) Get info to translate logical block number to inode number and then
translate that inode number into a filename.
This is where I get stumped. The HOWTO I found shows how to do this for an
EXT2/3 partition using debugfs, so I thought I could do the same thing
using jfs_debugfs, but I can't figure out how to get a valid inode value to
use with jfs_debugfs to get the filename(s).
If I use the 'i' (lowercase i "eye") or 'I' (uppercase I "EYE") options to
the display command in jfs_debug, it looks like I should translate logical
block 135537084 to inode -1635135392 (di_number output using the 'i' option
or iagnum using the 'I' option) based on the following results:
# jfs_debugfs /dev/sde1
jfs_debugfs version 1.1.12, 24-Aug-2007
Aggregate Block Size: 4096
> d 135537084 0 i
Block: 135537084 Real Address 0x81421bc000
[1] di_inostamp: 0x1c742f61 [19] di_mtime.tv_nsec: 0xc0749d49
[2] di_fileset: 1243045541 [20] di_otime.tv_sec:
0xdc1f418d
[3] di_number: -1635135392 [21] di_otime.tv_nsec:
0x1f603111
[4] di_gen: -766206507 [22] di_acl.flag: 0x66
[5] di_ixpxd.len: 3235549 [23] di_acl.rsrvd: Not
Displayed
[6] di_ixpxd.addr1: 0x54 [24] di_acl.size: 0x40d30d80
[7] di_ixpxd.addr2: 0x06010000 [25] di_acl.len: 5581489
di_ixpxd.address: 360877981696 [26] di_acl.addr1: 0x62
[8] di_size: 0xed13ca900322260a [27] di_acl.addr2: 0xd347078f
[9] di_nblocks: 0xd746af90069cd9ed di_acl.address: 424451442575
[10] di_nlink: -1245156732 [28] di_ea.flag: 0x0b
[11] di_uid: 1070598493 [29] di_ea.rsrvd:
Not Displayed
[12] di_gid: 552302989 [30] di_ea.size:
0x941bcb25
[13] di_mode: 0x3882aed2 [31] di_ea.len: 10209947
0127322 l-wu [32] di_ea.addr1: 0xb3
[14] di_atime.tv_sec: 0x69a9690b [33] di_ea.addr2: 0x7456872e
[15] di_atime.tv_nsec: 0x2d9b4085 di_ea.address: 770750973742
[16] di_ctime.tv_sec: 0xdd1dd831 [34] di_next_index: -2110134214
[17] di_ctime.tv_nsec: 0x1562ad04 [35] di_acltype: 0xd7477518
[18] di_mtime.tv_sec: 0x1160055d
- hit Enter to continue, e[x]it -
> d 135537084 0 I
Block: 135537084 Real Address 0x81421bc000
[1] agstart: 5338839946511003489 [12]
extsmap[0]: 20eb798d
[2] iagnum: -1635135392 [13] extsmap[1]:
3882aed2
[3] inofreefwd: -766206507 [14] extsmap[2]:
69a9690b
[4] inofreeback: 1412521693 [15] extsmap[3]:
2d9b4085
[5] extfreefwd: 100728832 [16] nfreeinos:
-585246671
[6] extfreeback: 52569610 [17] nfreeexts:
358788356
[7] iagfree: -317470064 [18] pad:
Not Displayed
[8] inosmap[0]: 069cd9ed [19] wmap: Type 'w'
[9] inosmap[1]: d746af90 [20] pmap: Type 'p'
[10] inosmap[2]: b5c86a84 [21] inoext: Type 'i'
[11] inosmap[3]: 3fd0095d
- hit Enter to continue, e[x]it -
But negative numbers just seem wrong, and of course I get an error when I
try to use it in the command for displaying inode information. Also, I
found a reference to a bug that might apply where JFS mistakenly put the
negative error number in the inode field, corrupting the data.
Any advice?
Craig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20130124/34a125ef/attachment.html>
More information about the mythtv-users
mailing list