0
  1. 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?

  2. 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 ..*

thanks=)

2
  • Let me guess: no backups either, right?
    – EEAA
    May 8, 2013 at 2:22
  • only one that is 2 month old with >99% of the data but still missing the recent >2500 edits and new files/folders. thanks
    – jonas
    May 8, 2013 at 2:27

1 Answer 1

0

Your best recovery option is UFS Explorer.

Obviously, it makes sense to get away from the convoluted loop device and filesystem arrangement.

See: How to recover XFS file system with "superblock read failed"

1
  • thanks Thats like testdisk&photorec for XFS? did you read that XFS_repair already worked on the cloned disk and that im just after finding out which pathes the 2000 removed inodes had or which are the latest edits or file/directory moves?
    – jonas
    May 8, 2013 at 2:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .