Repair of fsck damage after Ext4 File System

Repair of fsck damage after Ext4 File System

1. Fault background

The Ext4 file system does not have umount, and then performs the fsck operation to check consistency. As a result, the Ext4 file cannot be mounted, and the Directory becomes a file.

Error message: mount: wrong fs type, bad option, bad superblock

2. Fault Principle Analysis

If a fault occurs, logs and data are inconsistent, and the data in the normal file system is overwritten. Such faults often occur in Ext3 and Ext4 file systems. Fortunately. the journal log file is buffered and can be recovered from. find the corresponding information in the journal log file and paste it back to the corresponding location to recreate the original file.

3. Important case information

The first sector of the hard disk in Linux is the MBR sector. From the MBR partition table, we can see that there are two partitions in this case. The first partition is a swap partition with a total of 7.8 GB, and the second partition is an Ext4 file system with a total of 292 GB. The size is 300 GB.

The Ext3 and Ext4 file systems have the log function. In this case, you can find lost data in the. journal log file.

1. The block size is 4 kb, that is, 8 sectors.

2. The starting position of a Superblock is 1024 bytes, that is, Sector 2. The size of the Superblock is 2 sectors.

3. The description table of the block group starts from the first block, that is, starting from the 4096 bytes.

4. Important concepts of the case

Superblock: used to store configuration parameters (such as block size, total number of blocks, number of I-nodes) and dynamic information (number of idle blocks and number of I-nodes) of the file system ). The Superblock of the Ext4 file system starts at 1024 bytes, that is, the second sector.

Block group: all the space of the Ext4 file system is divided into several block groups. The structure of each block group is roughly the same.

Block group Descriptor Table: each block group corresponds to a block group descriptor. These block group descriptors are placed at the front of the file system and are called the block group Descriptor Table. Each block group descriptor is 32 bytes in size. It mainly describes block bitmap, I-node bitmap, and the address of the I-node table.

I node: Describes the time, size, block pointer, and other information of the file.

Block group Descriptor and super block position in the block: When the block size is two leaf areas, Block 0 is the guiding program or retaining block, and the super block starts from Block 1. When the block size is 4 fan areas, the boot program or the reserved block is located in the first two sectors of Block 0, and the super block is located in the last two sectors of Block 0. When the block size is 8 fan areas, the boot program or the reserved block is located in the 0-1 sector of Block 0, and the super block is located in the 2-3 sector of Block 0.

The overall structure of the Ext4 file system and the specific structure 1 of the block group are shown in.

5. Solution steps

Summary:

1. Find the super block through the super block backup in the. journal log file and determine the block size.

2. Find the super block through the super block backup in the. journal log file and recreate the super block information.

3. Find the directory node through the. journal log file and recreate (Restore) the directory.

4. Find the directory node in the. journal log file, find the node information of the file to be restored, and recreate (recover) the file.

First, use WinHex to open the Ext4 file system. We can see that the data in the 0-23 sector (including the super block and block group descriptor) is overwritten by log records. The log pages of the Ext3 and Ext4 file systems start with C0 3B 39 98. 2.

Figure 2

1. Determine the block size

The super block contains information about the block size. Find the backup of the super block from the. journal log. Use WinHex to find information about super-level blocks in the. journal log, marked as "53ef ". Find the super block method 3. The following figure shows how to view the block size in steps 4 and 5. The block size of the super block 0x18-0x1B is described. In this case, the block size is 4 kb.

Figure 3

View the block size 4 through the super block.

Figure 4

Or the WinHex template editor can also display the block size 5.

Figure 5

2. Rebuilding (recovery) Super blocks

Because the original file system's super block is damaged, you need to paste this part of the super block information back when restoring the file, that is, starting with Sector 2 or 1024 bytes.

After completing the above operations, the super block backup may be inconsistent with the actual super block value in some places. You need to modify it through the WinHex template manager. In this case, the block group of the super block is modified, which is in the 0th block group. 6.

Figure 6

3. Recreate (Restore) the block group description table

Because some block group description tables are damaged, find all the block group description tables in the. journal log file and paste them back.

In the. journal log file, 1 shows that the block group Descriptor Table is stored behind the super block. Therefore, when looking for a block group description table, you can find the super block first. Paste the contents of the block group Descriptor Table to the 4096 byte.

4. Recreate (Restore) The Directory

When we want to restore files in a folder, for example, we need to restore data in the kyproc folder. We found that these folders cannot be opened in WinHex. 7. Obviously this directory is corrupted. Open the node information and find that normal data is filled with logs, as shown in figure 8.

Figure 7

Figure 8

We can find its upper-level directory, namely the var folder. Right-click "open" to open the directory information of all files in the var file. Find the information of the kyproc directory to be restored. 12 32 EE 00 indicates its I-node number, 10 00 indicates its directory item length, and 06 indicates its file name length, 02 indicates that the file type is directory. 9.

Figure 9

Find the location of the kyproc directory under the directory block of the var folder, as shown in 10. The Marked red position is the result. The block number displayed at this position is 62399108.

Figure 10

You can locate the corresponding node in the kyproc directory based on the block number. Because manual node population is cumbersome, we can open the. journal log file, find its node information from it, and paste the corresponding information back.

The above method can be used to re-create (Restore) the directory, and restore the files in the directory through the same method. find the node information of the corresponding file in the journal log file, and paste it back to the original location to recreate (Restore) the file.

This article permanently updates the link address: