reassign 969495 extundelete
thanks

extundelete works by trying to look at the journal and tries to figure
out how to find old metadata blocks left over in older transactions in
the jbd2 journal file.  It's not part of e2fsprogs, but its own
separate package.

The extundelete program is a massive abstraction violation, and
whether or not it works is essentially an accident.  The ext4
developers don't consider themselves bound by any kind of guarantees
that extundelete will continue to work in the future.  We aren't going
to deliberately break it, but if we add new features to make ext4 more
flexible or robust (which would be the case with the metadata checksum
feature), and extundelete happens to break, our reaction will be:

        ¯\_(ツ)_/¯

My suggestion is that you use regular backups and/or userspace
solutions such as the trash-cli package, which implements the
Freedesktop.org Trash Can specification:

https://specifications.freedesktop.org/trash-spec/trashspec-1.0.html


It may be possible to teach extundelete to deal with the combination
of 64-bit and metadata_csum, but then as we add new features such as
the Fast Commit[1] feature, which improves ext4's benchmark
performance by 21% to 192% depending on the workload (and we are
looking to see if we can use transaction batching to further improve
Fast Commit's numbers), extundelete is going to break again.

[1] https://lwn.net/Articles/826620/

If the extundelete upstream package author and/or debian package
maintainer wants to update extundelete to keep up with new ext4
features, that would be great.  If not....

        ¯\_(ツ)_/¯

Cheers,

                                                - Ted


On Thu, Sep 03, 2020 at 09:10:12PM +0200, Jonas Jensen wrote:
> Package: e2fsprogs
> Version: 1.44.5-1+deb10u3 (armhf)
> 
> A deleted file can not be recovered on EXT4 partitions when created
> using the  "64bit" and "metadata_csum" flags.
> See test case below, I run Debian 10 buster on a BananaPi BPI-M1.
> The EXT4 partition is re-created on the same drive and partition. I
> re-tried this multiple times always with the same result, the test
> file could always be recovered when both "64bit" and "metadata_csum"
> were unset in the file system, and it could not be recovered when they
> were set.
> 
> mkfs.ext4 -O 
> has_journal,ext_attr,resize_inode,dir_index,filetype,extent,flex_bg,sparse_super,large_file,huge_file,uninit_bg,dir_nlink,extra_isize,^64bit,^metadata_csum
> /dev/sdl1
> mke2fs 1.44.5 (15-Dec-2018)
> /dev/sdl1 contains a ext4 file system
>         last mounted on /mnt on Thu Sep  3 20:15:24 2020
> Proceed anyway? (y,N) y
> Creating filesystem with 366284390 4k blocks and 91578368 inodes
> Filesystem UUID: 6072e511-7f38-4685-9e5b-e168bfef5ed4
> Superblock backups stored on blocks:
>         32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 
> 2654208,
>         4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
>         102400000, 214990848
> 
> Allocating group tables: done
> Writing inode tables: done
> Creating journal (262144 blocks): done
> Writing superblocks and filesystem accounting information: done
> 
> mount /dev/sdl1 /mnt && echo "delete" > /mnt/un && sync && rm /mnt/un
> && sync && umount /mnt
> 
> rm restore/* && extundelete --restore-all -o restore /dev/sdl1 && cat 
> restore/un
> NOTICE: Extended attributes are not restored.
> Loading filesystem metadata ... 11179 groups loaded.
> Loading journal descriptors ... 15 descriptors loaded.
> Searching for recoverable inodes in directory / ...
> 1 recoverable inodes found.
> Looking through the directory structure for deleted files ...
> 0 recoverable inodes still lost.
> delete
> 
> mkfs.ext4 -O 
> has_journal,ext_attr,resize_inode,dir_index,filetype,extent,flex_bg,sparse_super,large_file,huge_file,uninit_bg,dir_nlink,extra_isize,64bit,metadata_csum
> /dev/sdl1
> mke2fs 1.44.5 (15-Dec-2018)
> /dev/sdl1 contains a ext4 file system
>         last mounted on /mnt on Thu Sep  3 20:18:22 2020
> Proceed anyway? (y,N) y
> Creating filesystem with 366284390 4k blocks and 91578368 inodes
> Filesystem UUID: 5e744287-578e-4dc5-adf0-5e780bee2fdf
> Superblock backups stored on blocks:
>         32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 
> 2654208,
>         4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
>         102400000, 214990848
> 
> Allocating group tables: done
> Writing inode tables: done
> Creating journal (262144 blocks): done
> Writing superblocks and filesystem accounting information: done
> 
> mount /dev/sdl1 /mnt && echo "delete" > /mnt/un && sync && rm /mnt/un
> && sync && umount /mnt
> 
> rm restore/* && extundelete --restore-all -o restore /dev/sdl1 && cat 
> restore/un
> NOTICE: Extended attributes are not restored.
> Loading filesystem metadata ... 11179 groups loaded.
> Loading journal descriptors ... 0 descriptors loaded.
> Searching for recoverable inodes in directory / ...
> 0 recoverable inodes found.
> Looking through the directory structure for deleted files ...
> 0 recoverable inodes still lost.
> No files were undeleted.
> cat: restore/un: No such file or directory
> 
>    Jonas

Reply via email to