Creating a filesystem is the process of dividing the space in a partition into areas for data, inodes, and bookkeeping information. It is erroneously called 'formatting' in the vernacular. It is more precisely called 'high-level formatting' or 'erasing'. Prior to creating the filesystem, the partition and the device file used to access it must, of course, exist. The parameters needed for the filesystem must also have been decided. This includes the filesystem type, the blocksize, and any special parameters. 

Although the creation of other system-supported filesystems is similar, the specifics of this section will apply to the creation of an ext2, ext3, or ext4 filesystem.

Filesystem creation is the responsibility of the mkfs program. mkfs is not a single program. It is actually a front-end for a set of filesystem-creation programs, one per filesystem type. The most important options to mkfs are the filesystem type and the device file that indicates the partition on which the filesystem is to be created:

mkfs -t type [filesystem-specific parameters] device

The -t type option causes mkfs to invoke the appropriate filesystem-specific mkfs counterpart. These are named mkfs.type. Thus, the ext2 filesystem creation program is mkfs.ext2. (Each of mkfs.ext2, mkfs.ext3 and mkfs.ext4 is a link to mke2fs.) When the filesystem-specific version is started, it is given the filesystem-specific parameters.

For our discussion, we will concentrate on mke2fs (remember, this is used for ext2, ext3, and ext4). Here are the important options:

• -c  check for bad blocks. This will perform read/write tests on each block on the partition. A single -c performs read-only tests. Two -c options performs a destructive read/write test on each block. You may want to use this option for a brand new or very old disk. You may also want to use it as an added safeguard if the filesystem will contain data that is critical and is changed so often it is difficult to keep backed-up. Using this option significantly slows filesystem creation. -c uses the badblocks(8) program to generate a list of bad blocks. (I have never used this option.)
• -i N  create one inode per N bytes of data. Currently the default here is 4kB (4096). You can also specify this in a controlled fashion using -T
• -b blocksize  currently only 1024, 2048 and 4096 are allowed.
• -L label  set the filesystem label to label. It is your responsibility to ensure the label is unique! If you assign a duplicate label, the filesystem will not be mounted or may be mounted incorrectly. This is very important to realize if you have a dual-boot system with a second version of linux on it. During installation, linux will 'suggest' labels for each filesystem you create. The label will be the same as the mount point. Thus, when you install the second version of linux, make sure it does not try to assign a label that is in use by the other existing version! This problem can be avoided using UUIDs instead of labels.
• -U uuid  set the UUID to uuid. Since mke2fs automatically generates a UUID for the filesystem, this is not really necessary. However, in an automated application that wants to create the filesystem then mount it using its UUID, this could be useful. UUIDs can be created using uuidgen(1)
  
• -T use  change the heuristic for the proportion of inodes appropriately for the expected use of the filesystem. There are many supported values for use. The specifics are in /etc/mke2fs.conf (see mke2fs.conf(5). The most obvious ones are small (the default - one inode per small file), largefile (one inode per big file (currently 1MB)), largefile4 (one inode per very big file (currently 4MB))
• -n  do not actually create the filesystem, just show the parameters you would use. This can be used on an existing filesystem to show the blocksize and the blocks that contain the spare superblocks. In order for this to output the correct parameters you must give the same options to mke2fs as were used when the filesystem was created.

All data, of course, will be destroyed on the partition (unless the -n option is used), and the partition must not be mounted when mkfs is run.

Unless the device is specified in the fstab with one of the mount options user or users, mkfs must be run as root.

mkfs is noisy. The output consists of a progress report and the filesystem's parameters.

Filesystems can be identified later using one of three methods:

• by the device file. This is not wise as the device file may change if physical devices are added or removed.
• by the label. Labels are created by the administrator, who is responsible for ensuring they are unique
• by a uuid. The uuid is a long hex number that essentially guarantees uniqueness.

The label can be placed on the filesystem when it is created (using the -L label option above), or it can be added or changed using e2label:

e2label device [label]

Here e2label either outputs the current label on the device (if label is not specified) or relabels it.

We will discuss examining and/or changing the uuid on a filesystem in the section on filesystem tuning.

Creating a filesystem

As an example, we refer back to the 20GB filesystem which served as the example partition we created. The situation is this: we already have a filesystem created on it using default parameters and the filesystem was mounted at /new. We want to recreate it with some different parameters. Here are the parameters of the current filesystem

Suppose we want to use this filesystem for CD ISO files. We will thus choose the option -T largefile4 to mke2fs to lessen the number of inodes created. First, unmount the filesystem

Then create the new filesystem using mkfs

Examine the output of mkfs above and gather the following information:

• the filesystem label
• the block size
• the percentage reserved for overhead (i.e., reserved for the superuser)
• how many superblock backups there are and where they are stored.
• whether a journal was created and how large the journal was
• how often a complete check of the filesystem will be forced

We have created this filesystem with a very small number of inodes. A total of 5024 directories and files can be created on it, since that's how many inodes there are. This was a dangerous decision, but if we really use it for ISO images, whose size is typically .5GB, we should be fine. (Note: you would rarely specify the ratio of inodes yourself, as the wasted space is small by comparison. We are simply doing it for illustration.)

We did not specify a label when we recreated the filesystem. However, the configuration for the filesystem in fstab refers to the filesystem by the label /new, so we must add the label using e2label. (The label specified in the fstab is the same as the mount point (/new)):

Now we are ready to mount it. We will cover the full syntax of the mount command later. Since we have the configuration entered in the fstab, we can simply specify the mount point to mount the filesystem.

# mount /new

Next we will compare its numbers of inodes and disk blocks to the original filesystem.

Compare the numbers and see if you think reducing the number of inodes was worth the trouble.

A quick overview of these numbers indicates some inconsistencies: you would think that used + available should equal the total. It does not. The difference is 1028360 kB. This is just about 5% of 20564592, so there is the 5% reserved for root.

What is reflected in the 'used' quantity? We just created the filesystem. There should not be any space used yet! This used space is taken up by

• the inodes. there are 5024 of these, taking up just over 1MB (on ext4 there are 4 inodes per kB - you can verify this by looking at the size of an inode in tune2fs -l )
  
• the journal. looking back over the output of mkfs, the journal was allocated 32768 4k blocks for a total of 128MB
• interestingly, there are already some files and directories on the disk. This is shown by the usage of 11 inodes, and by running the command du -sk on /spare, which reveals a disk usage of 20kB. We will speak of this 'automatically-created data' (the lost+found area) below and again later when we learn about checking the filesystem.

The total for these three numbers is still about 128MB. This leaves about 40MB of space unaccounted for. This is filesystem bookkeeping space (free block lists, superblocks, and allocation bitmaps.) This bookkeeping overhead requirement is very small as a percentage of the overall filesystem space of 20GB.

The lost+found area

If you list our mounted filesystem, you find something surprising:

This lost+found directory is a repository for unreferenced inodes. It is used by the filesystem checking program fsck to save lost data if any is retrieved when the filesystem is analyzed. You should never delete this directory. We will discuss lost+found more in the section on checking the filesystem.

Resizing a filesystem

Resizing a filesystem using the command-line is very tricky, and, although it can be done, it is rarely feasible. The issue is always one of increasing the filesystem's size, and this requires first increasing the partition size. If you are lucky enough to have free space after the partition, this is possible, but that is rather rare. In case this is the situation, or you can safely delete and move the next partition, we will go through the tools briefly. The filesystem must be unmounted before any resizing operation, and you should back up your data first!

To increase the size of a filesystem you must first increase the size of the partition, keeping the current starting location. Once the partition size is increased you can use resize2fs to increase the size of the filesystem.

Note that I have little experience with resizing a real filesystem using these tools. Use them at your own risk.

If you are concerned that you may have to increase the size of your filesystems after the system is installed you may want to consider using the logical volume manager. It is much easier to increase the size of logical volumes than physical partitions.

We will revisit resize2fs when we discuss the logical volume manager.