On 10/12/2012 10:33 AM, Robert Henney wrote: > I have a jfs partition on a linux 2.6.32 install on which 3 sectors recently > became unreadable. I was able to write zeros to those sectors using dd and > the disk appears to think they're fine and readable again; at least no > sectors are marked reallocated or currently pending by the disk. > > dd of=/dev/sdc if=/dev/zero seek=640 count=1 bs=4096 > dd of=/dev/sdc if=/dev/zero seek=935 count=1 bs=4096 > dd of=/dev/sdc if=/dev/zero seek=1283 count=1 bs=4096 > > I would like to find out which files on the disk were in those blocks and > thus are now damaged. Since I have the logical block numbers I assume I > can get inode numbers from them somehow.
The data structure in the inode describes the blocks of a file, but nothing points from the block back to the inode. Assuming that the blocks are part of allocated files, one could recursively run "hdparm --fibmap" on every file in the filesystem and parse the output to identify which files contain those blocks. There should be an easy way to determine from the block maps whether those blocks are allocated or not, but I can't think of one. There are 8192 blocks represented in each dmap page, so those three blocks are mapped in the first dmap page. Looking at the dmaps in jfs_debugfs is awkward. Maybe it would be useful to add some new command to jfs_debugfs to walk the metadata and tell you how a block is used. I might play with that over the weekend if I find time. > > Tried using the 'd' command in jfs_debugfs but am not able to get anything > that remotely looks correct. Probably I'm not using a correct offset value, > but > I have no idea what I should give it. Is there a better method? "d 640 0" should just show you the zeroed block, but it won't tell you what it is used for. I don't think it will help. > > Disk /dev/sdc: 3907029168s > Sector size (logical/physical): 512B/512B > Partition Table: gpt > > Number Start End Size File system Name Flags > 1 2048s 3907028991s 3907026944s jfs primary Shaggy ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Jfs-discussion mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jfs-discussion
