File System Manipulation

Different people have various learning styles. For those of you who prefer examples rather than lectures, here are a few practical examples in which you learn how to create a file system within a file and mount it using the loopback file system a special file system that allows us to accomplish this useful feat. You can use the file system you create to experiment with and practice almost all the commands found in this chapter with no fear of damaging your system.

Creating a File System for Testing

Because most of us do not have a spare computer or hard drive on which to experiment and practice, we can make one of our own by creating an image file containing the file system of our choice and using the loopback file system to mount it. That way, we do not run the risk of accidentally wreaking havoc on the system itself. Although you could also use a floppy drive for these same exercises, their small size limits your flexibility.

Step 1 Make a Blank Image File

Use the dd command to create a file with a block size of 1,024 bytes (a megabyte) and create a file that is 10MB in size. (You need to have enough free space on your hard drive to hold a file this big, so adjust the size accordingly.) We want 10,000 1KB (1,024-byte) blocks, so we select a count of 10000.

If we wanted a floppy-sized image, we would have selected a block size (bs) of 512 and a count of 2880 for a 1.4MB floppy or 5760 for a 2.88MB floppy. Here's how to do that:

 # dd if=/dev/zero of=/tmp/fedoratest.img bs=1024 count=10000 

We see the computer respond with the following:

 10000+0 records in 10000+0 records out 

If we check our new file command, we see this:

 # file /tmp/fedoratest.img /tmp/fedoratest.img: data 

Step 2 Make a File System

Now we need to make the system think that the file is a block device instead of an ASCII file, so we use losetup, a utility that associates loop devices with regular files or block devices; we will be using the loopback device, /dev/loop0.

 # losetup /dev/loop0 /tmp/fedoratest.img 

Now we can format the file as an ext2 file system:

 # mke2fs /dev/loop0 

We see the computer respond as follows:

 mke2fs 1.27 (8-Mar-2003) File System label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 2512 inodes, 10000 blocks 500 blocks (5.00%) reserved for the super user First data block=1 2 block groups 8192 blocks per group, 8192 fragments per group 1256 inodes per group Superblock backups stored on blocks:     8193 Writing inode tables: done Writing superblocks and file system accounting information: done This file system will be automatically checked every 21 mounts or 180 days, \ whichever comes first. Use tune2fs -c or -i to override. 

Step 3 Mount Our Test File System

After your test file system has been created, you can experiment with the different options for the formatting commands you will be using. It will be useful to make a mount point for our image file

 # mkdir /mnt/image 

and then mount it

 # mount /dev/loop0 /mnt/image 

We can do this now because we already have the loopback file system associated with the image file. Later on if we remount it, we must use the following format to use the loopback option:

 # mount -o loop /tmp/fedoratest.img /mnt/image 

After mounting the new file system, we can look at it and see that the /lost+found directory has been created on it and that the df command returns

 # df -h /mnt/image File System      Size Used Avail Use% Mounted on /dev/loop0      \ 9.5M  13k 8.9M   1% /mnt/image 

To unmount it, use this:

 # umount /mnt/image 

Make a backup of the image just in case we break the original:

 # cp /tmp/fedoratest.img fedoratest.bak 

After the test file system is created, you can create directories, copy files to it, delete files, attempt to recover them, and, in general, create controlled chaos on your computer while you are learning and practicing valuable skills. If you damage the file system on the image beyond repair, unmount it, delete it, and create a new one (or copy a new one from that backup).

Using dumpe2fs

You can use the program dumpe2fs to examine the structure of your ext3 file system.

The syntax for the command is

 dumpe2fs [ -bfhixV ] [ -ob superblock ] [ -oB blocksize ] device 

To examine our image file system using dumpe2fs, first unmount it, and then use this:

 # dumpe2fs /tmp/fedoratest.img dumpe2fs 1.27 (8-Mar-2003) File System volume name:  <none> Last mounted on:         <not available> File System UUID:         03644acf-581c-410f-b4b6-10958992016e File System magic number: 0xEF53 File System revision #:   1 (dynamic) File System features:     filetype sparse_super File System state:        not clean Errors behavior:         Continue File System OS type:      Linux Inode count:             2512 Block count:             10000 Reserved block count:    500 Free blocks:             9664 Free inodes:             2501 First block:             1 Block size:              1024 Fragment size:           1024 Blocks per group:        8192 Fragments per group:     8192 Inodes per group:        1256 Inode blocks per group:  157 Last mount time:         Fri May 16 14:36:33 2003 Last write time:         Fri May 16 14:37:09 2003 Mount count:             2 Maximum mount count:     21 Last checked:            Fri May 16 14:35:39 2003 Check interval:          15552000 (6 months) Next check after:        Wed Nov 12 13:35:39 2003 Reserved blocks uid:     0 (user root) Reserved blocks gid:     0 (group root) First inode:             11 Inode size:              128 Group 0: (Blocks 1-8192)  Primary Superblock at 1, Group Descriptors at 2-2  Block bitmap at 3 (+2), Inode bitmap at 4 (+3)  Inode table at 5-161 (+4)  8018 free blocks, 1245 free inodes, 2 directories  Free blocks: 175-8192  Free inodes: 12-1256 Group 1: (Blocks 8193-9999)  Backup Superblock at 8193, Group Descriptors at 8194-8194  Block bitmap at 8195 (+2), Inode bitmap at 8196 (+3)  Inode table at 8197-8353 (+4)  1646 free blocks, 1256 free inodes, 0 directories  Free blocks: 8354-9999  Free inodes: 1257-2512 

A lot of information is in the metadata for the file: Every conceivable bit of information about the file system is displayed. Most of it is of use only to file system developers, not system administrators. Match up the information shown with the file system characteristics presented previously in this chapter to get a better picture of how it all fits together and what can be useful to you.

You can use the -b option to display a list of the blocks that are marked as "bad" and use the -f option to force dumpe2fs to ignore any problems it might have with file system flags it cannot read.

You can use the next two options in recovering lost data. The stressed out and desperate system administrator (that's you) would be the "file system wizard" referred to.

-ob superblock Use a specific alternate superblock when examining the file system. This option is not usually needed except by a file system wizard who is examining the remains of a very badly corrupted file system.

-oB blocksize Use blocks of "blocksize" bytes when examining the file system. This option is not usually needed except by a file system wizard who is examining the remains of a very badly corrupted file system.

Another program, debugfs, can be used to manipulate a file system as well as repair and recover a damaged file system. Because it is such a powerful command, it does not run by default with the capability to write any changes to the file system; that functionality must be explicitly enabled when the command is run. By entering the help command at the debugfs prompt, a menu of command options is displayed; the q command exits the program.

Mounting a Partition As Read-Only on a Running System

Remember that to do almost any kind of file system manipulation (formatting, checking, and so on), you should unmount the file system; by doing so, you avoid having any writes made to the file system, which would corrupt it.

How do you remount partitions on a running system? For example, to remount the /home partition (assuming that it is on a separate physical partition from root) as read-only to run fsck on it and then remount it as read-write, use the remount option for mount:

 # mount -o ro,remount /home 

NOTE

Remounting will not work if a normal user is logged in because /home will be busy (in use). You might need to switch to runlevel 1 (init 1), which is single-user mode, to remount /home.

Now we can run fsck on the partition. When done,

 # mount -o rw,remount /home 

puts it back in service.

If you reboot your system to mount the root file system read-only for maintenance (enter the maintenance mode, s, as described in Chapter 14.

 # mount -o rw,remount / 

will remount it read-write and you can continue on. That's easier than unmounting and remounting the device.

Converting an Existing ext2 File System to ext3

An existing ext2 file system is easily converted to ext3 to take advantage of the benefits of journaling. After you convert an existing file system, any other operating system including BeOS, Windows (with the appropriate drivers), and other Unix systems that have drivers to access ext2 partitions can access ext3 partitions. To those operating systems (and their drivers), your converted file system still looks just like an ext2 file system.

To begin the conversion to ext3, you use the tune2fs utility to add the journal to an existing ext2 file system. In this example, you are changing /dev/hda2, an already formatted ext2 partition.

 # tune2fs -j /dev/hda2 

It does not matter if hda2 is mounted or unmounted at the time of the migration; if it is mounted, you will see a new file, .journal, in the directory.

Next, edit the line for /dev/hda2 in /etc/fstab and change the value from ext2 to ext3. It will be mounted as an ext3 file system the next time you reboot.

NOTE

If you have decided to convert your root file system to take advantage of the benefits of the ext3 file system, bear in mind that you cannot run tune2fs -j on it while it is unmounted because you cannot unmount the root file system. Because the file system is mounted when you run tune2fs -j, the .journal file on it will be visible when you finish the migration.

When compiling a new kernel, make certain to include ext3 file system support in your new kernel by selecting that choice in your kernel configuration (see Chapter 38, "Kernel and Module Management"). Also, note that you do not need to perform the actions described in the next section if you have just freshly installed Fedora Core Linux.

Making an Initial Ramdisk

You need to create an initrd image file to load the ext3 driver and mount the root partition as an ext3 partition. The initrd file is an initial ramdisk that contains a small kernel and enough of the Linux OS to load drivers so that the real kernel and the rest of the operating system can load.

NOTE

If you forget to create the initrd file, your system will still boot, but it will mount the root partition as ext2. That's very clever none of the other journaling file systems are as forgiving.

To create the file, run the mkinitrd utility before you reboot.

 # mkinitrd /boot/initrd-2.6.7-1.478.img 2.6-7-1.478 

The first argument is the name of the initrd file that will be placed in the /boot directory. The name can be anything; the name shown here follows the usual naming convention; you can find a number of other naming options in the mkinitrd man page. The second argument after the mkinitrd command is the version of the kernel you want to use. The value you enter here does not have to be the version you are currently using, but it must match the version you use when you boot (and the kernel must support ext3).

After you run the utility, edit /boot/grub.conf or /etc/lilo.conf to change the initrd loaded at boot time. For GRUB, add this same line beneath the kernel line in the section that references your kernel:

 initrd (hd0,0)/boot/initrd-2.6.7-1.478.img 

If you use LILO, add the following line to the appropriate LILO stanza:

 initrd=/boot/initrd-2.6.7-1.478.img 

NOTE

LILO is no longer used in Fedora, but you may have it on an older system upgraded to Fedora.

Examine an initrd Image File

The initrd.img file is automatically created during the installation process (if necessary) or with the mkinitrd command. You never need to examine it, but if you are curious about what's in the initrd.img file, just take a look: It is really just a gzipped ext2 file system. To examine it, first copy it to the /tmp directory and add the .gz suffix to it:

 # cp /boot/initrd-2.6.7-1.478.img /tmp/initrd-2.6.7-1.478.img.gz 

If your system does not have an initrd.img file in /boot, mount your boot floppy and see if it has one. Next, uncompress it as follows:

 # gunzip /tmp/initrd-2.6.7-1.478.img.gz 

Mount it as follows:

 # mount -o loop /tmp/initrd-2.6.7-1.478.img /mnt/image 

and browse the directory to your heart's content.

Not every system will have an initrd.img file. It is typically used to load device drivers for file systems (such as Reiser) or hardware (such as the Promise RAID IDE controller) that must be in place before the system can continue booting. Some floppy-based Linux distributions use initrd.img to load a minimal operating system that can then uncompress and load the working file system from the floppy.

You can also mount .iso images in the same way, but remember that they are always read-only because of the nature of the underlying iso9660 file system; you can write to the other images unless you explicitly mount them as read-only. If you want to read and write to the files in an ISO file system, you must first copy the files to a device that is mounted read-write, make your changes, and then use mkisofs to create a new .iso image. This is a common "gotcha" for many users.

Examine a Floppy Image File

The floppy boot images on the installation CD have different configurations to address special situations, as explained in their accompanying documentation. If you find the need to modify one for your unique situation or if you are curious to know what's in any of the boot floppy images that are on the install CD, mount the image using the mount command as follows:

 # mount -o loop /image /mnt/image