how to find the full original file/directory path of some damaged XFS inodes?
and how to list the last modified few 10000 inodes (=edited or moved files/directories) rapidly among millions of total files?
- is it better to ddrescue only the damaged website.image filesystem in a file or the whole harddrive including its parent filesystem that is supposedly not damaged despite the disk has some errors? (while "1". does not, this may requires to read the whole story below)
An nearly full XFS image mounted -o loop on debian runs productive since years on the same drive. A million of files are read every day, only some are written in batches every few days.
/dev/cciss/c0d9 1953449048 1950392335 3056714 100% /website ' (smart unvisible due to HP p410 raid controller) /dev/loop0 1950358937 1937866163 12492775 100% /var/www/website
While moving a batch of files the filesystem said bye a few times already. this time it could not be mounted anymore and was attempted with xfs_repair and xfs_repair -f -L to no avail, stopping at I/O error scaning inodes...
ddrescue /dev/cciss/c0d9 /dev/cciss/c0d6 /ddrescuelog in a first run the ddrescue log knew about 50 errors totaling about 2800kb
after several times: ddrescue -c1 --direct --retrim --try-again /dev/cciss/c0d9 /dev/cciss/c0d6 /ddrescuelog 500 errors and only 440 kb supposedly still missing.
(also forgot to use the log once, overwriting the first 20gb again until i stopped it. but no issues i suppose since it will write in exactly the same place on the destination drive?)
now repairing the filesystem on the new disk, it removed about 2000 inodes damaged and 1500 files/directories just like this one:
bad magic number 0xe5a0 on inode 3270245798 bad version number 0x12 on inode 3270245798 bad inode format in inode 3270245798 bad magic number 0xe5a0 on inode 3270245798, resetting magic number bad version number 0x12 on inode 3270245798, resetting version number bad inode format in inode 3270245798 cleared inode 3270245798 **entry "index.html" at block 0 offset 6848 in directory inode 3270245561 references free inode 3270245798 clearing inode number in entry at offset 6848...**
*- also: as of the billion inodes i suppose xfs_repair did consume 30GB of ram and crashed in the final step (which is common and doesnt matter i suppose)
- reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ..*