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 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 the user files located in /home to it. When done, we 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.
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 might not be playing nicely 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.
Creating the Partition Table and Formatting the Disk
After it is 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 (refer to '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 identifies bad blocks and doesn't use them; bad blocks would only corrupt our data if we didn't mark the file system to ignore them.
Mounting 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 the one of 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 the 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, and additionally selects 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, we must 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 enter:
# 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 the newly created home partition and delete the files in the partition that contains the thisistheoldhomepartition file.
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.
Logical Volume Management
The previous example showed you how to add a new drive to overcome a lack of disk space. What if this could be done without all the mounting and file copying? That's where logical volume management (LVM) is useful. Using LVM, disk space from multiple drives can be pooled into a single logical volume.
As with any new technology, there is a steep learning curve involved in using LVM, not the least of which is its vocabulary. Within this vocabulary, partitions are known as physical volumes, or pvs. We add pvs to a volume group that defines a logical volume on which we can create our file system.
On a heavily used system, the files being backed up can change during the backup, and the restored files
