Root partition full - how do I increase size?
 

Help! I don't know how this happened, but happened it did. The root volume/partition is full. The hard drive itself is 230 gb with more than 200 gb free. I did some research on how to fix this, but I'm a relative newbie and most of the fixes seemed dangerous.

I don't have physical access to the server, but do have telnet and Webmin access. Can anyone tell me how to increase the size of the root volume? It appears I have to unmount it, but doing so would disable my access it would seem.

Below is information on root.

Volume name lv_root Volume size 4.88 GB
Blocks allocated from volume group 59315 out of 59315 Allocation block size 4 MB
Device file /dev/vg_tekafs/lv_root Current status Mounted on / as ext4
Volume access Read/write Allocation method Non-contiguous
Volume striping Disabled (always allocate from start)
Free space 0 bytes Free percentage 0 %
Physical volumes allocated dm-2 4.88 GB

Thanks for your help.

Tony

Just, curious this a virtual machine? Can you use all the available space?

I'm not sure you can grow the root partition without downtime.

You could partition the available space and map/move the directories which are filling your root partition. Start with /home, then /var and if you really need to /usr. Mount the new space first (ie under somewhere like /mnt), move teh files and create a sym link to where it lives on the new partition.

There is almost no useful info in the original post. We need to know how the disk is configured, where the free space (if any) is. At least LVM gives you the prospect of easily increasing the LV.
No knowing your distro, try searching the Redhat doco, and have a look at howto for LVM on tldp.

Thanks for the replies. Sorry for being so slim on the info.

The system is not a virtual machine. It is a Fedora 12 installation. I'm not where I can access the system right now, but I can tell you it has a partition that contains the home folder. That partition has about 180 gb free.

When I finish rescuing another client's Windows server this afternoon, I will get to a place where I can access the Fedora system and post more information about the system. Thanks for offering to help. Hopefully, I can get the Linux server sorted out before Tuesday.

Tony

Below is more information about the configuration of the Fedora 12 installation. As mentioned above and shown below, the root partition is full and I am trying to find a way to fix that.

Bmxcess, you mention partitioning free space. I have never tried to do that on a live, production system. Are you saying another partition should be made out of the free space in the number 2 partition (noted below)? There is at least 180 gb free in the number 2 partition.


PARTITIONS
Number Type Size Start End
1 Linux 203.95 MB 1 26
2 Linux LVM 231.70 GB 26 30272


LOGICAL VOLUMES LVM (ver. 2.02.53)

Volume name lv_root Volume size 4.88 GB
Blocks allocated from volume group 59315 out of 59315 Allocation block size 4 MB
Device file /dev/vg_tekafs/lv_root Current status Mounted on / as ext4
Volume access Read/write Allocation method Non-contiguous
Volume striping Disabled (always allocate from start)
Free space 0 bytes Free percentage 0 %
Physical volumes allocated dm-2 4.88 GB


Volume name LogVol02 Volume size 14.65 GB
Blocks allocated from volume group 59315 out of 59315 Allocation block size 4 MB
Device file /dev/vg_tekafs/LogVol02 Current status Mounted on /usr as ext4
Volume access Read/write Allocation method Non-contiguous
Volume striping Disabled (always allocate from start)
Free space 9.75 GB Free percentage 67 %
Physical volumes allocated dm-2 14.65 GB


Volume name LogVol03 Volume size 7.32 GB
Blocks allocated from volume group 59315 out of 59315 Allocation block size 4 MB
Device file /dev/vg_tekafs/LogVol03 Current status Mounted on /usr/local as ext4
Volume access Read/write Allocation method Non-contiguous
Volume striping Disabled (always allocate from start)
Free space 6.70 GB Free percentage 92 %
Physical volumes allocated dm-2 7.32 GB


Volume name LogVol04 Volume size 7.81 GB
Blocks allocated from volume group 59315 out of 59315 Allocation block size 4 MB
Device file /dev/vg_tekafs/LogVol04 Current status Mounted on /var as ext4
Volume access Read/write Allocation method Non-contiguous
Volume striping Disabled (always allocate from start)
Free space 6.53 GB Free percentage 84 %
Physical volumes allocated dm-2 7.81 GB


Volume name LogVol05 Volume size 191.41 GB
Blocks allocated from volume group 59315 out of 59315 Allocation block size 4 MB
Device file /dev/vg_tekafs/LogVol05 Current status Mounted on /home as ext4
Volume access Read/write Allocation method Non-contiguous
Volume striping Disabled (always allocate from start)
Free space 167.84 GB Free percentage 89 %
Physical volumes allocated dm-2 191.41 GB

The first question I'd be asking is, why has it filled up? Is it because you've been progressively adding more software, or did this happen suddenly?

I'd log on to the machine, and start looking at directory and file sizes using du - are any of the directories that are in the root volume unusually large? Are there any processes that are logging to the root volume (rather than into /var/log)? Are there any old files you can delete?

Another line of inquiry would be whether another filesystem was not mounted, when files were being written to it. Could (for example) the /home directory contain files, that are taking up space in root, but are hidden by the filesystem mounted over them?

You could also possibly look at moving files in one of the larger non-system directories (/opt? /srv?) onto another volume, rather than having to expand root.

:twocents:

Shouldn't be any need to move anything. I'm guessing all those are in one VG - if so shrinking the /home will free up space that can be used for other LVs, including the root. That's the benefit of LVM.
See the guide I linked to above. Also the Redhat admin guide (or similar) will have something similar. Might even be an LVM admin tool for it these days.

Thanks for all the help on this problem. I did resolve it. I was going to shrink /home and increase / as recommended, but first, I deleted a backup that had not finished, which was made to a USB drive. After doing that / had 85% free space. It seems, even though the USB drive has 1 terrabyte of space, the backup wrote to the volume group that holds the / directory. So, now I'm going to have to figure out why that is happening, but the situation has become curious - down from critical.

Tony

I had to delete my entire machine on vmware because of this issue. I didn't get a stepwise process on how to solve this issue but I just rebuilt a new system and do not want the same errors happening. I was updating software when I noticed the problem.