debugfs - rdump broken?

  • Jonathan Liversidge

    Hi all

    Verison: debugfs 1.41.6 (30-May-2009)

    I'm attempting to recover data from a *very* messed up 10Tb storage array (over iSCSI).

    I'm using the following command (using superblock 32768 because main s/b is corrupt)...

    debugfs -w -s 32768 -b 4096 /dev/sde1

    ...which even though it takes about 20 minutes for the command prompt to appear, allows me to navigate what is left of the filesystem (when I reset certain superblock values such as hash_seed, inodes_per_group and so on - values that I know from when the filesystem was originally created. Without setting these values, debugfs returns: "Ext2 inode is not a directory" when attempting to get a directory listing).

    Anyway, running...

    ls -l

    ...lists the files/directories successfully (although some have "Illegal inode number..." in the listing).  The directory I am trying to salvage looks OK, but when trying to 'rdump' to an existing location on the local filesystem the following is returned:

    debugfs: rdump /DATASTOR/ /RECOVER/FILES
    rdump: File exists while making directory /RECOVER/FILES/

    However, if I set the target location on the local filesystem to a non-existent directory (by deleting the 'FILES' directory on local system), it returns the following:

    debugfs: rdump /DATASTOR/ /RECOVER/FILES
    rdump: No such file or directory while statting /RECOVER/FILES

    Has anyone else experienced this problem at all or is there something obvious that I'm missing?

    Thank you in advance.


    • Jonathan Liversidge


      I'll answer my own question...

      Took a look in...


      ...and found that the destination (in my case "RECOVER/FILES") needs to have permissive permissions at the root level, not just the sub directory.  A simple chmod 777 sorted the problem.

      rdump most certainly isn't broken and is a life saver.



Log in to post a comment.