EXT2 filesystem

In my machine, there is an ext2 filesystem /dev/sda6 which its mount point is /fs2.

Firstly, I should know the location of superblocks and the size of block.
[root@localhost ~]# dumpe2fs /dev/sda6 | grep –i superblock
dumpe2fs 1.40.8 (13-Mar-2008)
  Primary superblock at 1, Group descriptors at 2-2
  Backup superblock at 8193, Group descriptors at 8194-8194
  Backup superblock at 24577, Group descriptors at 24578-24578
  Backup superblock at 40961, Group descriptors at 40962-40962
  Backup superblock at 57345, Group descriptors at 57346-57346
  Backup superblock at 73729, Group descriptors at 73730-73730
[root@localhost ~]# dumpe2fs /dev/sda6 | grep –i ‘block size’
dumpe2fs 1.40.8 (13-Mar-2008)
Block size:                               1024 

From the above, I knew there are 5 backup superblocks and the block size is 1024 bytes. The location of primary superblock is at 1. The locations of these 5 backup superblocks are at 8193,24577,40961,57345 and 73729 respectively. If you want to know the filesystem’s block size, there are another two ways that you can use tune2fs and ext3grep commands. For example,
[root@localhost ~]# tune2fs –l dev/sda6 | grep –i ‘block size’
[root@localhost ~]# ext3grep /dev/sda6 | grep –i ‘block size’ 

Then, I destroyed the superblock as below.
[root@localhost ~]# dd if=/dev/zero count=1 bs=1024 seek=1 of=/dev/sda6 

I checked the effect, and found I still could change to /fs2 directory. I could still list its contents. But the system gave me error messages when I tried to create a file or copy files.
[root@localhost ~]# cd /fs2
[root@localhost ~]# ll
total 19
drwx—— 2 root root 12288 2009-06-25 08:57 lost+found
-rw-r—r—1 root root   135 2009-06-25 18:15 qaz
 … … 

[root@localhost fs2]#cp qaz wsx
cp: overwrite  `wsx’? y
cp: writing `wsx’: No space left on device
 [root@localhost fs2]#cp qaz edc
cp: cannot create regular file `edc’: Input/output error 

When I run the dumpe2fs command, it told me the superblock had been destroyed.
[root@localhost fs2]#dumpe2fs /dev/sda6
dumpe2fs 1.40.8 (13-Mar-2008)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sda6
Couldn’t find valid filesystem superblock. 

I recovered the superblock.
[root@localhost ~]# dd if=/dev/sda6 count=1 bs=1024 skip=8193 seek=1 of=/dev/sda5

After that, I checked if I can create and copy files. I found they worked. And the command dumpe2fs could display normally. 

EXT3 filesystem

In my machine, there is another ext3 filesystem /dev/sda5 which its mount point is /fs3.

Check the location of superblocks and the size of block.
[root@localhost ~]# dumpe2fs /dev/sda5 | grep –i superblock
dumpe2fs 1.40.8 (13-Mar-2008)
  Primary superblock at 0, Group descriptors at 1-1
  Backup superblock at 32768, Group descriptors at 32769-32769
  Backup superblock at 98304, Group descriptors at 98305-98305
  Backup superblock at 163840, Group descriptors at 163841-163841
  Backup superblock at 229376, Group descriptors at 229377-22937
[root@localhost ~]# dumpe2fs /dev/sda5 | grep –i ‘block size’
dumpe2fs 1.40.8 (13-Mar-2008)
Block size:                               4096 

From the above, I knew there are 4 backup superblocks and the block size is 4096 bytes. The location of primary superblock is at 0. The locations of these 4 backup superblocks are at 32768, 98304, 163840, and 229376.

Destroy the superblock.
[root@localhost ~]# dd if=/dev/zero count=1 bs=4096 seek=0 of=/dev/sda5 

I found I still can change to /fs3 directory. But when I listed its contents, there is nothing. I used dumpe2fs command to check, it told me the superblock has problem. Then I tried to recover the superblock like the above approach, however, it did not work. I restarted the system. The system displayed it unable to resolve the filesystem and could not boot up. I entered the maintenance mode and tried to recover using the method as below. It did not work.
(Repair filesystem) 1 # e2fsck –f –b 32768 /dev/sda5
e2fsck 1.40.8 (13-Mar-2008)
e2fsck: Device or resource busy while trying to open /dev/sda5
Filesystem mounted or opened exclusively by another program? 

Then I used another method, after I reboot the system it worded.
(Repair filesystem) 2 # e2fsck –f  /dev/sda5
(Repair filesystem) 3 # reboot 

From the test, I realized that the information of the filesystem’s superblock is very important. We’d better backup it to the root because we can still read it through maintenance mode even if the system can not boot up normally. Don’t forget run the following command.
#dumpe2fs /dev/sda5 > /dumpe2fs-sda5