Rescue tool

[erkinalp]

A few years ago, some email in the f2fs development mailing list mentioned a filesystem corruption, which would only be recoverable by rescanning all the inodes and reconstructing the checkpoint. I have had a similar corruption issue. My fsck output follows:

Info: Debug level = 3
Info: Segments per section = 1
Info: Sections per zone = 1
Info: sector size = 512
Info: total sectors = 536870912 (262144 MB)
Info: MKFS version
  "Linux version 5.4.0-72-generic (buildd@lcy01-amd64-019) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #80-Ubuntu SMP Mon Apr 12 17:35:00 UTC 2021"
Info: FSCK version
  from "Linux version 5.4.0-74-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #83-Ubuntu SMP Sat May 8 02:35:39 UTC 2021"
    to "Linux version 6.2.0-35-generic (buildd@bos03-amd64-016) (x86_64-linux-gnu-gcc-11 (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #35~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct  6 10:23:26 UTC 2"
Info: superblock features = 0 : 
Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000

+--------------------------------------------------------+
| Super block                                            |
+--------------------------------------------------------+
magic                         		[0xf2f52010 : 4076150800]
major_ver                     		[0x       1 : 1]
volum_name                    		[]
minor_ver                     		[0x       b : 11]
log_sectorsize                		[0x       9 : 9]
log_sectors_per_block         		[0x       3 : 3]
log_blocksize                 		[0x       c : 12]
log_blocks_per_seg            		[0x       9 : 9]
segs_per_sec                  		[0x       1 : 1]
secs_per_zone                 		[0x       1 : 1]
checksum_offset               		[0x       0 : 0]
block_count                   		[0x 4000000 : 67108864]
section_count                 		[0x   1fe85 : 130693]
segment_count                 		[0x   1ffff : 131071]
segment_count_ckpt            		[0x       2 : 2]
segment_count_sit             		[0x       a : 10]
segment_count_nat             		[0x      6e : 110]
segment_count_ssa             		[0x     100 : 256]
segment_count_main            		[0x   1fe85 : 130693]
segment0_blkaddr              		[0x     200 : 512]
cp_blkaddr                    		[0x     200 : 512]
sit_blkaddr                   		[0x     600 : 1536]
nat_blkaddr                   		[0x    1a00 : 6656]
ssa_blkaddr                   		[0x    f600 : 62976]
main_blkaddr                  		[0x   2f600 : 194048]
root_ino                      		[0x       3 : 3]
node_ino                      		[0x       1 : 1]
meta_ino                      		[0x       2 : 2]
cp_payload                    		[0x       0 : 0]
crc                           		[0x       0 : 0]
version                       Linux version 5.4.0-74-generic (buildd@lgw01-amd64-038) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #83-Ubuntu SMP Sat May 8 02:35:39 UTC 2021
Info: total FS sectors = 536870912 (262144 MB)
	Invalid CP CRC offset: 0
	Invalid CP CRC offset: 0
[f2fs_do_mount:3512] Can't find valid checkpoint

The rescue tool should satisfy the following requirements:

1. In case the tool finds multiple inodes with overlapping blocks, the one updated the latest should take precedence.
2. Where possible, the tool should be written in a manner that prefers bogus files to unlinked files.
3. If checksums fail during the rescue, they should just be ignored, in accordance with requirement 2.
4. When there is enough RAM, the tool should construct the tables (superblock & checkpoints) at RAM, then write the result to the disk all at once. This is necessary to allow multiple FS rescue attempts going in parallel.