Relocating a File System

Many home users start with a single disk partition that mounts not only the root file system files, but also all the other files. Although this might work quite well for most home users, there might come a time when the physical disk becomes full. Adding another drive and moving part of the file system there is not difficult, but it is the source of many questions from new Linux users. This section of the chapter explains how to do this kind of file system relocation.

In this example, we will install a new IDE hard drive to /dev/hdb (the primary slave drive), create a single partition on it, format it as an ext3 file system, and move all of the user files located in /home to it. Once done, we will make it mount, by default, at the /home mount point by editing the /etc/fstab file.

Installing the New Drive

First, physically install the drive, making certain that the master/slave jumpers are set correctly to set the drive as a slave drive. Also be certain that the jumpers are set correctly on the existing master drive. (Some drives require a different jumper setting, depending on whether they are a single master drive or a master drive with a slave drive; others offer a "cable-select" option to automatically set the drive status.) Failing to ensure that the jumpers are set correctly is a common error made even by people who are familiar with computer hardware.

After you have installed the drive, it must be correctly detected by the BIOS. Many modern BIOSes have an autodetect feature, or you can manually enter the drive CHS information in the BIOS (found on the drive label or documentation).

NOTE

Linux can ignore the BIOS-provided CHS information and use information that you provide when loading the kernel, passing it as a kernel argument. Although this is a very powerful Linux option, it is now only used when working with obsolete BIOSes from more than three or four years ago and when you are attempting to use a hard drive that is larger than the BIOS was designed to address. In these cases, the CHS information helps the bootloader program know where the kernel is on the disk and helps the kernel understand how the data on the drive is organized, enabling Linux to make older hardware remain useful long after it has become obsolete. For more detailed information, you can look at the Large Disk HOWTO and the BootPrompt HOWTO if you have problems with drive geometry and the BIOS.

Most modern large drives use the LBA setting (Logical Block Addressing) to deal with the BIOS size limitations. If the drive is not detected, check the power connection, the IDE cable connection (the red stripe usually goes next to the power connector, but always double-check), and the master/slave jumpers. If all these are fine, you might have a bad drive, or the two hard drives if made by different manufactures) might not be playing nice with each other (especially if they were made by different manufacturers).

To check further, reset the jumper of the new drive to make it the master drive, disconnect the old drive, and plug in the new one in its place. If the new drive is now correctly detected, suspect some incompatibility between the drives. Always make cable changes to the drives with the power off, or you will damage the drive.

TIP

If you were to examine the partition table with a hexadecimal editor, you would find that with only 10 bits in which to store the partition's cylinder offset (an index to data on the disk); no disk can have any more than 1,024 cylinders.

One creative way to get around that limitation is to increase the number of heads so that the number of cylinders can remain small enough to fit the partition table. This scheme is known as Logical Block Addressing, or LBA. Modern BIOSes (post-1998 or so) support it, but older ones do not. But because Linux is capable of being told about the drive geometry at boot time, it is not as big a problem to Linux users as it is to users of other operating systems. For more detailed information, you can look at the Large Disk HOWTO and the BootPrompt HOWTO if you have problems with large hard disks.

Creating the Partition Table and Formatting the Disk

Once installed and recognized by the BIOS, a partition table needs to be created. Use fdisk (or the program of your choice) to create a single partition on the drive, remembering to write the changes to the MBR before you exit the program (see "Creating the Partition Table," earlier in this chapter).

Formatting the drive is next. Because we are creating a new ext3 file system, we use the j option, as

 # mke2fs -cj /dev/hdb1 

Notice that we are checking the drive (using the -c option) for bad blocks as we format. Even though it adds considerable time to formatting the drive, an initial bad block check is always a good idea. The program will identify bad blocks and not use them; bad blocks would only corrupt our data if we didn't mark the file system to ignore them.

Mount the New Partition and Populating It with the Relocated Files

For the example that follows, it is assumed that /home was a directory that was part of the partition mounted at /, not a separate partition to begin with.

Here, we create a temporary mount point and mount the new partition:

 # mkdir /mnt/newpartition # mount -t ext3 /dev/hdb1 /mnt/newpartition 

It is now time to copy all the files from /home to /mnt/newpartition. It is important that we preserve the time and date stamps for the files and the permissions. We're copying entire directories and subdirectories, so we use one of our three basic copying methods (tar, cpio, or cp) that best accommodates this:

 # cp -a /home/* /mnt/newpartition 

We need to modify /etc/fstab so that our new ext3 partition will be mounted correctly:

 /dev/hdb1   /home ext3  defaults     1 2 

Here, we have chosen to use the default mount options for the ext3 partition. The defaults are identical to those for the ext2 file system, as well as additionally selecting the default data=ordered journaling mode.

Anytime we reboot, the new partition containing the copied files will automatically be mounted at /home. But before we do that, cd to /home and enter this:

 # touch thisistheoldhomepartition 

Now we can mount the new partition:

 # umount /mnt/newpartition # mount /dev/hdb1 /home 

Note that if you do an

 # ls -al /home 

you will not see the thisistheoldhomepartition file we created with the touch command. So what happened to the old files? They are still there, but just hidden because we mounted a directory "over" them. When we are satisfied that all is well, we can unmount our newly created home partition and delete the files in the partition that contains the thisistheoldhomepartition file.

TIP

You can use the previously explained technique as a placeholder or warning for any temporarily mounted file system so that you do not mistakenly think that the file system is mounted when it is not.