Analyzing and Repairing Ext2Ext3

If you happen to encounter problems on your Ext2/Ext3 file system, the file system offers some commands that can help you to analyze and repair the file system, as described in this section.

e2fsck e2fsck is a file system check utility that works on both Ext2 and Ext3. If you think something might be wrong with your file system, run e2fsck. You should make sure, though, that the file system on which you run it is not currently mounted. Because this is hard to accomplish if you want to run it on your root file system, it is not a bad idea to use the automatic check that occurs every once in a while when mounting an Ext2/Ext3 file system. This check is on by default, so don't switch it off.

When you run e2fsck on an Ext3 file system, the utility will check the journal and repair any inconsistencies. Only if the superblock indicates that there is a problem with the file system will the utility check data as well. On Ext2, e2fsck will always check data, because this is the only option. Normally, e2fsck will automatically repair all errors it finds, unless an error requires human intervention, in which case e2fsck will notify you so that you can use one of the advanced options by hand. Table 5-3 provides an overview of the most useful options that e2fsck has to offer.

Table 5-3. Most Useful e2fsck Options



-b superblock

-j external_journal

Use this option to read one of the backup superblocks. Unlike when using the mount command, you can refer to the normal block position where the file system can find the backup superblock, which is block 32768 in most cases.

This option lets e2fsck check for bad blocks. If it finds them, it will write them to a specific inode reserved for this purpose. In the future, the file system will avoid using any of these blocks. Be aware, though, that bad blocks are often an indication of real problems on your hard drive. Use the -c option with e2fsck as a temporary solution until you can replace your hard drive.

Use this option to force checking, even if the file system seems to be without problems.

Use this option to specify where the external journal can be found. You'll need this option if your file system uses an external journal.

This option tells fsck to automatically repair everything that can be repaired without human intervention.

This option assumes an answer of yes to all questions. This goes further than default -p behavior and will also automatically enter yes to questions that normally require human intervention.

dumpe2fs and tune2fs

In some situations, e2fsck may not do its work properly. In such cases, two useful utilities to analyze a little bit further what is happening are dumpe2fs and tune2fs. dumpe2fs dumps the contents of the superblock and the information about all block group descriptors (see Listing 5-5). On large file systems, e2fsck will give you huge amounts of output. If you just want to see information from the superblock, use it with the -h option, which makes it more readable.

Listing 5-5. dumpe2fs Shows the Contents ofthe Superblock andAll Group Descriptors

Filesystem volume name: Last mounted on: Filesystem UUID: Filesystem magic number: Filesystem revision #: Filesystem features: Default mount options: Filesystem state: Errors behavior: Filesystem OS type: Inode count: Block count: Reserved block count: Free blocks: Free inodes: First block: Block size: Fragment size: Blocks per group: Fragments per group: Inodes per group: Inode blocks per group: Last mount time: Last write time: Mount count: Maximum mount count: Last checked: Check interval: Reserved blocks uid: Reserved blocks gid: First inode: Inode size:

<not available>

3babfd35-de36-4c8l-9fb9-la988d548927 OXEF53 1 (dynamic) filetype sparse_super (none) not clean Continue Linux 490560 979933 48996 898773 490529 1

1024 1024 8192 8192

8 02:58:33 2008 8 02:58:33 2008

Tue Jul Tue Jul 1

Tue Jul 8 02:58:16 2008 0 (<none>) 0 (user root) 0 (group root) 11 128

Group 0: (Blocks 1-8192)

Primary superblock at 1, Group descriptors at 2-5 Block bitmap at 6 (+5), Inode bitmap at 7 (+6) Inode table at 8-518 (+7)

2029 free blocks, 4070 free inodes, 2 directories Free blocks: 532-2560 Free inodes: 17, 20-4088 Group l: (Blocks 8193-16384)

Backup superblock at 8193, Group descriptors at 8194-8197 Block bitmap at 8198 (+5), Inode bitmap at 8199 (+6) Inode table at 8200-8710 (+7) 2095 free blocks, 4088 free inodes, 0 directories Free blocks: 14290-16384 Free inodes: 4089-8176 Group 2: (Blocks 16385-24576)

Block bitmap at 16385 (+0), Inode bitmap at 16386 (+l)

Inode table at 16392-16902 (+7)

5749 free blocks, 4088 free inodes, 0 directories

Free blocks: 16387-16391, 16903-22646

Free inodes: 8177-12264

If you see a parameter that you don't like when using dumpe2fs, you can use tune2fs to change it. Basically, tune2fs works on the same options as mkfs.ext3, so you won't have a hard time understanding its options. Consult the man page for more details on tune2fs.


If you really are ready for a deep dive into your file system, debugfs is the utility you need. Make sure that you use it on an unmounted file system only. The debugfs tool works at a very deep level and may severely interfere with other processes that try to access files while you are debugging them. So, if necessary, take your live CD and use debugfs from there.

After starting debugfs, you'll find yourself in the debugfs interface, which offers some specific commands. You will also recognize some generic Linux commands that you know from a bash environment, but, as you will find out, they work a bit differently in a debugfs environment. For example, the Is command in debugfs shows you not only file names, but also the number of blocks in use by this item and the inode of this item, which is very useful information if you really need to start troubleshooting (see Listing 5-6).

Listing 5-6. The ls Command in debugfs Works Differently [email protected]:/# debugfs /dev/system/root debugfs 1.40.8 (lB-Mar-2008) debugfs: Is

2 (12)

2 (12)

.. 11 (20) lost+found 6135809 (12) var




5095425 (12) srv 335873 (12) etc




24577 (16) cdrom 24578 (20) initrd.img




1073153 (12) usr 1417217 (12) bin




1966081 (12) home 1572865 (12) mnt




6086657 (12) root 2277377 (12) sbin




360449 (12) sys 5586945 (12) opt




24579 (16) vmlinuz 4808705 (16) tftpboot



clonezilla 1785857 (12) isos

24580 (36) initrd.img-2.6.24-16-server 24581 (3692) 335873 (END)

24580 (36) initrd.img-2.6.24-16-server 24581 (3692) 335873 (END)

In case you are wondering how this information may be useful to you, imagine a situation where you can't access one of the directories in the root file system anymore. This information gives you the inode that contains the administrative data on the item. Next, you can dump the inode from the debugfs interface to a normal file. For instance, the command dump <24580> /24580 would create a file with the name 24580 in the root of your file system and fill that with the contents of inode 24580. That allows you to access the data that file occupies again and may help in troubleshooting.

This information may also help when recovering deleted files. Imagine that a user tells you that he has created three files, /home/user/filel, /home/user/file2, and /home/ user/file3, but has accidentally deleted file2 and desperately needs to get it back. The first thing you can do is use the lsdel command from the debugfs interface. Chances are it will give you a list of deleted inodes, including their original size and deletion time. Listing 5-7 shows an example.

Listing 5-7. The lsdel Command in debugfs Gives You an Overview ofDeleted Files [email protected]:/# debugfs /dev/sdal debugfs 1.40.8 (l3-Mar-2008) debugfs: lsdel



Mode Size


Time deleted



100644 16384


17 Sun Jul 6 11:27:

:49 2008



100644 16384


17 Sun Jul 6 15:41

:01 2008


0 100644


1/ 1 Tue Jul

8 06:33:45 2008

3 deleted inodes found. (END)

3 deleted inodes found. (END)

As Listing 5-7 demonstrates, in the information that lsdel gives you, you can see the inode number, original owner, size in blocks, and, most important, the time the file was deleted. Based on that information, it's easy to recover the original file. If it was the file in inode 233030, from the debugfs interface, use dump <233030> /originalfile to recover it. Unfortunately, due to some differences between Ext2 and Ext3, lsdel works well on Ext2 but rarely works well on Ext3. In that case, you have to use some more advanced techniques.

Given the fact that the user in our example has created some files, it may be interesting to see what inodes were used. Let's say filel still uses inode 123, file2 uses 127, and file3 is removed, so you can't find that information anymore. Chances are, however, that the inode that file3 has used was not too far away from inode 127, so you can try to dump all inodes between inode 128 and 140. Chances are that this will allow you to recover the original file, thanks to dumpe2fs.

There are many other commands available from debugfs as well. The help command from within the debugfs interface will give you a complete list. I recommend that you check out these commands and try to get an impression of the possibilities they offer, because you may need to use them some day.

Computer Hard Drive Data Recovery

Computer Hard Drive Data Recovery

Learn How To Recover Your Hard Drive Data After A Computer Failure.

Get My Free Ebook

Post a comment