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.
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:
| Road #1 | Road #2 |
| We need to install the hardware, partition the drive and format the partition we would like to use. For this example we assume that the disk is /dev/hdb, and we created three partitions: /dev/hdb1, /dev/hdb2, /dev/hdb3. All of them are formated using the ext3 filesystem. /dev/hdb1 shall be our new home. /mnt/castle shall be a temporary mountpoint. Thus a directory with that name must be created. We must be sure that no user is logged in, and no services access the user’s data. So we need to change into a single-user runlevel without networking. |
|
Unmount the old /home woody:/# umount /home |
|
Mount the new partition to a temporary location woody:/# mount -t ext3 /dev/hdb1 /mnt/castle |
Mount the new partition to /home and the /dev/hda2 to a temporary location woody:/# mount -t ext3 /dev/hda2 /mnt/castle woody:/# mount -t ext3 /dev/hdb1 /home |
Copy the data to the new partition woody:/# cp -a /home/* /mnt/castle/ |
Copy the data to the new partition woody:/# cp -a /mnt/castle/* /home/ |
Unmount the old /home and the temporary location woody:/# umount /homewoody:/# umount /mnt/castle |
Unmount the old /home (in the temporary location) woody:/# umount /mnt/castle |
mount the new partition as /home woody:/# mount -t ext3 /dev/hdb1 /home |
|
| If you have verified that everything works as normal you can reuse /dev/hda2 (the old /home) for something else. | |
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
Move the old /usr to a temporary location woody:/# mv /usr /usr.old |
Recreate the mountpoint /usr and mount the new partition to it. woody:/# mkdir /usrwoody:/# mount -t ext3 /dev/hdb2 /usr |
Copy the data to the new partition woody:/# cp -a /usr.old/* /usr/ |
| If you have verified that everything works as normal you can free the diskspace used by /usr.old by deleting it. |
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 |
Unmount /tmp woody:/# umount /tmp |
Remove the old /tmp-mountpoint woody:/# rm -rf /tmp |
Rename /tmp.new to /tmp woody:/# mv /tmp.new /tmp |
| If you have verified that everything works as normal you can reuse /dev/hdc1 (the old /tmp) for something else. |
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:
/var)cp -ax /var /home/var
/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.du -sh /var vs. du -sh /home/var) Anybody better ideas?mv /var /old-varln -s /home/var /varrm -rf /old-var
Copyright (c) by the authors.
Prior to editing, authors agreed to license their contributions by the terms of the GPL.
See our licensing page for details.
Linux® is a registered trademark of Linus Torvalds.