Ext4 Undelete

Like the ext3 file-system before it,  ext4 is almost famuous for having no undelete facility. The ability to recover recently unlinked (deleted) files is something many users would like.

Ext3 file-system users have recently (2008) had the help of Carlo Wood's  ext3grep tool which has greatly improved the chances of finding and recovering recently deleted files. Accidentally deleted files are usually in the category of recently deleted.

Accidents Will Happen

I'm here because a thoughtless script executed

rm -rf ../linux*

It wiped out my Linux kernel development git repository (./linux-2.6/). The system has a logical volume (LV) containing the ext4 file-system that is mounted to /home/all/SourceCode. With-in that is a directory for every source-code package I touch - there are hundreds. Amongst those is the directory that serves as the root of all my kernel development, with sub-directories for each repository I work with:

./linux-2.6/
# tracks Linus's tree and contains remotes from various other trees
# (linux-pci, x86-tip, etc.)

./ubuntu-jaunty/
./ubuntu-intrepid/
./ubuntu-hardy/
./linux-next/
# etc...

The script I used was one I'd not touched before, in the Ubuntu Jaunty repository (/ubuntu-jaunty/): debian/scripts/misc/prepare-ppa-source. It then executed the offending command:

rm -rf ../linux* include/config .config

which matched the ../linux-2.6/ directory. An earlier command in the script had issued an error message so I interrupted it with Ctrl+C - unfortunately not soon enough! I did notice that ../linux-next/ escaped because of that interruption.

Back-ups Are Not The Point

This being an active development tree that is constantly changing it only gets backed up every week or so. The changes in the repository over the intervening period are also quite widespread and involve the working-tree and the git repository itself.

Recovery Strategy

Seeing as ext4 is backwards-compatible with ext3 it seems to make sense to extend ext3grep to, in effect, become ext4grep. I'm currently taking a crash-course in ext4 file-system design and structures alongside the same for ext3 (thanks to Carlo's  fantastic documentation).

Next I shall get my head around Carlo's code and then develop a design and implementation plan to add ext4 structures, functions and options.

Testing

I've copied the file-system onto a spare hard disk which will become my working test bed - it can be the subject of write-tests as I proceed and be recreated from the original LV.

File-System Details

sudo lvdisplay  /dev/Ubuntu/SourceCode
  --- Logical volume ---
  LV Name                /dev/Ubuntu/SourceCode
  VG Name                Ubuntu
  LV UUID                AXViil-Kics-0kQa-4tLh-a9T3-2fAr-oIphgp
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                30.00 GB
  Current LE             7680
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:7

sudo dumpe2fs -h /dev/Ubuntu/SourceCode
dumpe2fs 1.41.4 (27-Jan-2009)
Filesystem volume name:   SourceCode
Last mounted on:          <not available>
Filesystem UUID:          7e109a37-ffd8-4826-b54d-a2a28937406e
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1966080
Block count:              7864320
Reserved block count:     392588
Free blocks:              5454071
Free inodes:              1468979
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1022
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
RAID stride:              32699
Flex block group size:    16
Filesystem created:       Tue Feb 10 15:46:21 2009
Last mount time:          Fri Mar 13 00:49:49 2009
Last write time:          Sat Mar 14 01:09:01 2009
Mount count:              12
Maximum mount count:      20
Last checked:             Tue Mar  3 12:13:29 2009
Check interval:           15552000 (6 months)
Next check after:         Sun Aug 30 13:13:29 2009
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      a281ded4-4e01-4485-a1d7-da1d34f19a49
Journal backup:           inode blocks
Journal size:             128M

Resources

 Ext4 features
 Ext4 origins
 How to recover a damaged ext4 file system? from the linux-ext4 mailing-list
 ext3grep discussion group
 ext3grep source code