This question has sprung up more than once on a mailing list I have subscribed to. Since these threads can become long and confusing, I have put up the procedure to cope with full partitions.

First I will describe the fundamentals of harddrives, partitions, filesystems and mountpoints. This description might not be exhaustive, so you want to look up these topics in your favorite book or online resource.

After that, the basic steps in changing partitions for certain directories are quite obvious. So we will look at them in detail. Then, we will look at some special circumstances that might complicate the process.

Note that this guide assumes that you are using filesystems on traditional Linux partitions (as described below). However, newer Linux distributions are increasingly using “LVM” (logical volume management) by default. While we'll describe LVM in greater detail in another page, the important point is that one can dynamically resize LVM volumes, and the filesystems on them, without having to copy or move files around in the ways that are described below.

To find out if you're lucky you can run the command:

vgdisplay -s

… as the root user, of course. If you're using LVM then your system will have a suite of utilities installed including the “volume group display” command. This command will summarize any “volume groups” that are configured along with information about whether there is any free space available in each. Any free space in the volume group can be assigned to any of the logical volumes that are in the same group (It's rare to have more than one VG on any given system; but possible). (You can see a “columnar summary” of your logical volumes using the lvdisplay -C command). Even if you don't have any free space you can add additional hard disks to a volume group, and then use that to resize any logical volumes. LVM is very flexible and requires a little extra learning curve over the traditional Unix/Linux storage model.

This document contains procedures which can, in case of error or typos, damage your data and/or your configuration. Backup your data. The steps described are done as 'root', and thus you can wipe your whole installation with one little command (Only seven keypunches required: rm -rf *). Backup your data. Use this document only as a tutorial for you to practice in a testing-environment. Backup your data. Don't do this on important machines, unless you know that you can do it and how to do it without my help. Backup your data.

There is a paragraph about /etc/fstab at the end of this document. Read it. It is important.

Backup your data!

The cp commands are without the -v option. If you set -v you will get a line of output for each file copied. This will make it impossible to spot error-messages.

Backup your data!

You have been warned.

<dl><dt>Harddrive</dt><dd>This is the actual hardware that stores a string of 1s and 0s. Most are build with magnetic disks, but they can also be made up of RAM or other neat technologies you plug into your USB-slot. The Harddrive is addressed via special files inside /dev (like /dev/hda or /dev/sdc)</dd><dt>Partition</dt><dd>The harddrive must be divided into one or more partitions. These are logical sections of the harddrive that are independent of each other. For the OS the partitions are like separate disks. They are addressed by the device-file of the drive with the partition number added to it. (like /dev/hda1 or /dev/sdc5). Partitions are created with the 'fdisk'-command or one of its front-ends. </dd><dt>Filesystem</dt><dd>Moving up to the next level, we add another logical structure to those partitions: In order to store files, we need to have a filesystem on those partitions. There are several to choose from: ext2, ext3, reiser, xft, vfat, and many more. These are created using the 'mkfs'-command. Remaking the filesystem (also called reformatting) destroys all data stored on that partition, without touching the other partitions. </dd><dt>to mount / mountpoint</dt><dd>In order for users to make use of the filesystem (on the partition on the harddrive), we need to tell the OS where we would like to have it in our directory-tree. So, when we say: "OS, I want to access the partition /dev/hda3 using the ext3 filesystem as /home" &nbsp;we mount the filesystem. Since partitions and filesystems are pretty dependent on one another, some people also say 'mount the partition'. It depends which aspect you want to emphasize. The mountpoint is the directory you want to use for accessing the partition. This directory must exist. Whatever is in that directory will be hidden after mounting by the contents of the mounted partition. So it is usually left empty. The /mnt directory can be used for temporarily mounting filesystems. Modern distributions (July 2003) create directories inside /mnt for this purpose. We will also do that in this document.   </dd></dl>

So, lets explore some disks: The df-command is your friend when changing partitions around. Run it often, just to see what is going on. So you will not get lost. Well, at least you will not get lost that easy

stw@woody:~$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1             3.9G  1.1G  2.7G  27% /
/dev/hda2            10.0G  9.8G  0.2G  98% /home

So, we see that the partition holding my user's data is getting full. I go out and buy a new disk, but how can my users profit from it? We need to move the user-data to the new disk and mount it as /home. There are 2 roads that lead to the same goal:

As you can see, both ways vary in the point in time when the new partition gets the mountpoint it will keep.

So after a while, after working more and installing more software, we notice that the /-partition (/dev/hda1) is getting full. So what can we do here? It is not advisable to assign / to a new partition, except you are very good in configuring boot-managers like grub or lilo. So we will search for the directory that uses most space on our disks:

woody:/# du -s * | sort -gr
807032  usr
131640  etc
84872   var
13044   home
6252    lib
2776    sbin
2424    bin
944     boot
804     root
588     tmp
[snip]

In this case, /usr is the largest directory. And since most applications are stored there, it is a perfect candidate for getting a new partition. Since it is not on a partition of its own, yet, we will need the mv-command to free the mountpoint. After the procedure, /usr will reside in /dev/hdb2

Sometimes we make mistakes during install and maybe assign the big 60GB-partition /dev/hdc1 to /tmp. After a while, we want to correct that:

|Copy the old /tmp to a temporary location

woody:/# cp -a /tmp /tmp.new|

Let's say, the /usr directory should get the partition that is assigned to /tmp. This is the case that can get really confusing. But if we break the task apart into smaller steps, it gets easy. Just take the partition from the /tmp-directory like we did in the third example. Then, as a second step, assign the partition to /usr, like we did in the second example. As stated above, 'df -h' is your friend.

I'm glad you asked. During this document we did the mounting and unmounting by hand. We supplied the three parameters neccesary to the mount-command, thus /etc/fstab was not needed. After you changed the partitions around, it is very important to change /etc/fstab accordingly. Otherwise, on reboot, the partitions will be mounted to their old locations and you will be in a complete mess. You will not know which data is up-to-date and which is outdated. It could even be mixed!
So update your fstab!

Let's say, your /-Partition is getting pretty full, but you have enough space on your /home-Partition. Here is a quick and dirty fix for the problem:

1. Pick a directory you want to move. (let's assume /var)
2. Go into single user mode.
3. cp -ax /var /home/var
   • This will copy /var to /home/var. -a will keep owner's rights, symlinks, and will do the copy recursively. -x will cause it to not copy subdirectories in /var which are not actually on the same partition/filesystem as /var. The mountpoints will be copied but not the data within mounted partitions.
4. Make sure the copy is ok (du -sh /var vs. du -sh /home/var) Anybody better ideas?
5. mv /var /old-var
6. ln -s /home/var /var
7. Reboot and test the system for some time.
8. If everything works ok, rm -rf /old-var