When you are working with file systems, you need to be aware of several tools. The first tool is not specifically for file systems, but without it you cannot create one. This tool is fdisk, which is used to create partitions. The file systems are then created on the partition.

As with many Unix dialects, the Linux command to create a filesystem is mkfs (for make filesystem). It takes the -t option followed by the name of the filesystem you want to create. Typically, mkfs calls a different program that does the actual work. For example, mke2fs is used to make the file system. If you install a system from scratch, the installation process will run this for you with some fairly legitimate defaults. However, if you are adding a new hard disk to your system, the device nodes may be there, but the file systems are not. Therefore, you will need to create them.

Note that the mke2fs program will only make ext2fs file systems. Other programs can make these file systems, but I will continue to restrict our discussion to the ext2fs. For details on the various options, check out the mkfs man-page.

Think back to the discussion on the file system structure. By default, the system creates the inode table with a ratio of one inode for every 4096 bytes. If you have several large files, the file system will be full before you run out of inodes. However, if you are running a news or mail server, the average size of the files is less than 4096 bytes. Therefore, you will probably run out of inodes before the file system fills up.

Therefore, if you have a news or mail server, it is a good idea to use mke2fs manually to create the file system before you add any files. Remember that the inode table is at the beginning of the file system and takes up as much room as it needs for a given number of inodes. If you want to have more inodes, you must have a larger inode table. The only place for the inode table to grow is into your data. Therefore, you would end up overwriting data. Besides, running mke2fs “zeroes” out your inode table so the pointers to the data are lost anyway.

The tune2fs command is also just for the ext2fs and is used to modify the file system parameters. You can adjust the behavior on errors, the maximum interval between forced cleanings. Using the -l option will show you the current configuration parameters.

Last is one program that you don’t want to learn very well: e2fsck. This is the file system checker. This program is designed to check and fix your file system. The only time you get to know it very well is when there is something wrong with your file system that you need to correct.

If for some reason your system goes down improperly, the file system will not be marked as “clean.” In some cases, not being clean (also called being dirty) simply means that the system didn’t set the clean bit. When you reboot, e2fsck checks the file system, all is wells and you can continue to work.

If your luck is not with you, however, there are times when not clean is not good. You might have opened files when the system went down and the data weren’t written to the disk, so when the system came back up you had empty files. You may have situations in which the directory entry is trashed and the files exist in the file system (it has an inode and occupies data blocks) though there is no entry in any directory.

When you run e2fsck, it goes through several phases to check the sanity of each file system and to clean up as necessary. In the first phase or pass, e2fsck checks all the files in the file system. Rather, it is more accurate to say that it checks all the inodes. The human concept of a file includes the file name, though when e2fsck checks things during the first pass, it only checks the inode, which includes making sure that the mode (permissions of the file) is valid, all the data blocks point to valid block numbers, etc.

Part of this check is to see that now two inodes point to the same data blocks. Remember that you can have two file names point to the same inode, as is the case with both hard and symbolic links. However, they represent the same set of blocks on the hard disk. Having two inodes accessing the same data blocks is not a good thing. Also during this pass, the inode and block bitmaps are checked.

If e2fsck noticed any problems, it runs though again (pass 1b-1 d) to make sure things are straightened out.

Next, in pass 2, directories are checked. The directories are checked as “unconnected” objects, that is, unrelated to inodes. First, the dot (.) entry is checked to see that it exists and points to the current directory and that the dot-dot ( ..) exists. Note that checking the dot-dot entry to ensure that it points to the parent directory is not done until pass 3. This is to keep the directories unconnected.

At this point, e2fsck has looked at all of the directories and all of the inodes at least once. Part of what e2fsck does to speed things up is to keep all of this information in memory. Therefore, it doesn’t have to go back to the disk again. Instead, the remainder of the checks are all performed in memory.

In pass 3, e2fsck first checks the directories as connected objects. Here, the paths of each directory are traced back to the root. To do this, e2fsck needs to check each of the dot-dot (..) entries to make sure it is valid. Any directories that cannot be traced back are linked into the lost+found directory of the respective file system.

In pass 4, e2fsck checks the reference count of all inodes. Part of this is to make sure that there are as many files pointing to a particular inode as the inode thinks there are. If a file exists but does not point to a valid inode, it is also linked into the lost+found directory.

In the last pass, e2fsck checks the validity of the system information, such as the block and inode bitmaps against which we computed what is actually on the hard disk. Because what is in memory was just verified, this would overwrite what is on the hard disk.

I have had many cases where the first (default) superblock was corrupt and e2fsck could not continue automatically. Instead, I needed to run it manually and tell it to use a different superblock. For example, like this:

e2fsck -b 32768 /dev/hda12

where 32768 is the location of the first superblock copy. For filesystems with 1k blocksizes, a backup superblock can be found at For filesystems with 1k blocksizes, a backup superblock can be found at block 8193; for filesystems with 2k blocksizes, at block 16384; and for 4k block� sizes, at block 32768. block 8193; for filesystems with 2k blocksizes, at block 16384; and for 4k block� sizes, at block 32768. 32768 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000 You can use the -p to automatically repair the filesystem. I will be quite frank and say that I typically do not try to repair any filesystem manually. However, whether you do or not will depend on how important the data is, or better yet, how well you can afford to loose some of it. Since repairing a file system manually can be a avery time consuming process and the file system cannot be used until the repairs are completed, it might be in your interested to simply fix the file system automatically and continue from there or to recreate the filesystem and restore from backups.