Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
$df -h
Filesystem            Size  Used Avail Use% Mounted on
                       32G   30G     0 100% /
tmpfs                 7.8G     0  7.8G   0% /dev/shm
/dev/sda1             485M   51M  409M  12% /boot
                       17G  295M   16G   2% /home

I have a 70gb hard drive and I've run out of space but it looks like there is lots of space left in /home. How can I repartition this? Do I really have to manage this manually?

share|improve this question
It might not matter 100%, but can you include the Linux distribution you're working on and the kernel version. – EightBitTony Jun 8 '12 at 8:12
...and more importantly what filesystems are these formatted as? – symcbean Jun 8 '12 at 8:20
up vote 5 down vote accepted

You have to reduce the size of /home in 2 steps: reduce size of filesystem, reduce size of logical volume. This cannot be done online, so be sure to unmount /home before (i'm assuming you use some ext filesystem):

See this example:

umount /lvm-test
e2fsck -f /dev/volg1/logv1
resize2fs /dev/volg1/logv1 512000
lvreduce -L-800M /dev/volg1/logv1
mount /dev/volg1/logv1 /lvm-test

If you don't want to calculate you can resize the filesystem to minimum size, then reduce the lv and extend the filesystem to max size by calling resize2fs /dev/volg1/logv1 without size ;) But be careful. If the lv is smaller than the filesystem, data will be lost

When finished you should see some Free PE in vgdisplay. Then you can extend lv_root. Extending can be done online, so no need to unmount:

lvextend -L +800M /dev/mapper/vg_app001-lv_root
resize2fs /dev/mapper/vg_app001-lv_root
share|improve this answer
I know by experience,that this manipulation can cause great damage on the data (you might even loose all your data). But it depend of the distribution (it happen to me on centos 6 and RHEL 6). But that's the way – Anarko_Bizounours Jun 8 '12 at 9:10

In my experience running out of space is often symptomatic of a lack of attention to the general question of managing the volume of information you are storing. In your example, you've used 30Gb of a partition mounted as / and have 16Gb left in a partition mounted as /home. A short-term fix could be to move some sizeable piece of data to a subfolder of /home from its present location; you may be able to use a symbolic link to maintain access to it. But if you've accumulated (say) 20Gb of data over the last six months, then in four months' time you'll be in trouble again.

I have visited many businesses where the client complains of running out of space on the server, and I have found folders full of photographs of the company picnic or the contents of someone's iPod, usually associated with an employee who long since left their employ. This is the kind of data which can be discarded or moved to other storage media such as DVD.

On the other hand if right now you have a legitimate need for over 30Gb of online storage then a 70Gb drive probably isn't going to meet your needs for very long.

The other point I'd make is that when building Linux servers, it's my usual practice to just have one partition for swap space, and the rest of the drive as /. That way you don't run out of partition space until you've filled the whole disk.

share|improve this answer

For a quick fix, check what takes up a lot of space with du --max-depth=1 / (probably you will find something in /var :) , then move that into a subdirectory of /home and bind-mount/symlink it into the root filesystem.

BTW, are you sure there are no allocatable extents left in the vg - in which case you could just create another filesystem, move stuff there and mount it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.