/var full - need to resize
 

Hello,

I have a cPanel server, and it's been running for over 6 months now. The problem comes now that as we have been collecting logs and installing additional programs, the /var partition has become 100% full.

The problem is, we have to keep all the logs of the server, so deleting them is not an option, basically I need to resize the /var partition.

Now don't get me wrong, I’m no Linux beginner, but I am when it comes to partitioning, so if anyone can help with a step to step tutorial, I would be very grateful.

Current system:
Really I wish to take some out of the /home (say 4GB) and then add it to the /var partition. Now I understand that it may not be possible to do that, so if it's not, how do I create a partition on the /home one (of 8GB), and move the /var over to the new partition?

Thanks,
Richard Anderson.

Well, you're using LVM so you don't need to actually repartition anything. You can just reduce the /home partition and assign the space to /var. That is, use resize2fs (or resize_reiserfs, depending on what filesystem you're using). Then use lvreduce to reduce the size of the /dev/mapper/VolGroup00-LogVol05 logical volume by 4GB, and then assign that space to /dev/mapper/VolGroup00-LogVol02 with lvextend. Note that if you're using xfs, then you're stuffed because you can't currently shrink an xfs filesystem, only grow it.

Assuming you're using reiser or ext3, then it's straightforward. Of course, you should probably unmount the filesystems before doing anything. Reiser is a bit easier, since we can shrink it by a given amount: e.g.

will lop off 4GB.

resize2fs though, wants the new absolute size, so we can use python to calculate that:

so that will be the new size of the /home volume in K. (Note that 293702680 is in K, so the size would be '(293702680*1024)-4*1024**3' bytes, then divide by 1024 to get K, which is the same as the above). Thus,

should do the trick. Then use

to reduce the /home volume, and

to assign that space to /var (note that lvextend will eat all the available space by default, so we don't need to specify a size).

Obviously, read all the relevant man pages first, and triple check all calculations before you do anything, and make sure the filesystems are backed up of course.

Thank you for the reply soggycornflake.

I think i'm on a ext3 filesystem, but how do I check I am correct? Also, to unmount it I would just use: "unmount /dev/mapper/VolGroup00-LogVol02"?

mount (without arguments) will list all mounted partitions and the fs type (and a bunch of other stuff). E.g, mine is

Yup, though the command is 'umount' (no n after the u, unix developers are too lazy to type unmount ;)). You might need to drop down to single user to umount /var, since some daemons may have open files on it.

You may not need to reduce anything. It depends on if your volume group is fully allocated. Run vgs to see if you have anything left in the "VFree" column to allocate to /var. If not, you'll have to reduce some other filesystem, as soggycornflake said. Or add another harddisk and use pvcreate and vgextend, and finally lvextend/resize2fs on your /var logical volume.
That would work (without the "n"), but it would be simpler to just type umount /var You may have a bit of trouble doing this on a server in multi-user mode though. I expect /var might be in use (therefore not-unmountable). You may have to drop down to single-user mode.

[edit]Oops, I missed the part where soggycornflake already mentioned single-user mode. Sorry about that![/edit]

I would recommend you read the LVM HowTo: http://tldp.org/HOWTO/LVM-HOWTO/

Thanks for all the help so far guys :D

First off, haertig;

32MB :P Not that much really.

soggycornflake;

So ext3.

Therefore, I should run the following commands?

Thanks.

My comments:

(1) You have a huge amount of space allocated to /home. 259Gb. You are only using 20Gb of that. It is wasteful to have all this unused space allocated to /home.

(2) My opinion ... when using LVM (as you are), allocate only what you need and leave some unallocated space for future use. It's much safer to extend a filesystem from unallocated space than to reduce a different filesystem to free up space for the one you want to extend. Filesystem reducing is MUCH scarier than extending. This does not help you for your current situation, but consider it for the future.

(3) You need to backup /home before proceding. Your current 20Gb usage should fit on 4 or 5 DVD's. I would not neglect this step unless you consider the contents under /home as expendable data. Always plan ahead for a potential disaster.

(4) I would take your /home all the way down to 22-25Gb. That will leave you LOTS of space to allocate later as needed. Allocate it to /home, /var, /usr or wherever you need it, but only AS you need it, don't preallocate and get yourself into the situation where you are now (needing to shrink a filesystem).

That will not be enough. I don't know if you're leaving out steps for clarity, or because you don't realize they are needed. For one, I doubt you can just use resize2fs to shrink a filesystem out of the blue. Your data will be scattered and fragmented and you can't just lop off the trailing end of the filesystem. I have never shrunk a filesystem personally, only extended them, so I can't tell you specific steps. I assume some form of defragmentation or consolidation must come before the resize downwards. I do not think resize2fs has this capability, but I can't say for sure. Second, after the shrinking, you will need to run lvreduce on that volume. Next, you would unmount and lvextend /home. Then run fsck on /home. Then run resize2fs on /home. Then remount /home.

Thanks for the reply.

/home is where all the hosted files are stored, it's at 259GB as we are ever expanding (aka, this is a hosting server) I would be willing to reduce it to 200GB minimum.

On the left commands out comment, nope :P I have no idea about filesystems and partitions on linux, I have no clue about the commands or what steps I need to take, which is why I requested a step by step tutorial of sorts.

I learn by example, and i've been trying to find an example like mine for days now... But can't... Which is why I came here (Afterall, if google can't find the answers, i'm sure the experts can ;))

Thanks.

I assumed that resize2fs handled all that. The man page mentions block/inode relocation:

However, I also, have never shrunk a filesystem, so I could be wildly wrong, it may only apply to extending the fs.

But, in any case, haertig is correct, it's generally much easier, and safer, to extend a filesystem rather than shrink it (for future reference).

Haertig gave the answer - in post #7. Applies in general - LVM or not. Backup the data, delete the offending partition(s), reallocate sensibly, and restore the data.
I keep 2 100Gig USB drives for things like this. Why 2 ??? - 2 copies ...

Resize2fs is supposed to do the job - I've never had it work satisfactorally. Other swear by it.
All that said, do you *really* need all those logs ???.
Online ...
Uncompressed ... ???

Have a look at something like logrotate. Easy to do, and could save a lot of grief.
What about moving all the logs to /home and symlink'ing ???.

Thanks for your replies.

One last question. If I was to add another hard drive (say 80GB) how easy would it be to give all 80GB to /var?

Trivial. That is what LVM is for. Shutdown the system. Plug in the new drive. Boot into single-user mode. Run pvcreate on the new drive. Add it to your existing volume group. Unmount /home. Use lvextend to allocate more space to it. Run e2fsck on it. Run resize2fs on it. Remount it. Go to multi-user mode. You're done! Shouldn't take more than two or three minutes to complete all these steps (ignoring the powerdown, hardware install, and reboot parts). Check out the LVM HowTo I mentioned in a previous post. All these steps are covered there.

Given that you're a hosting service for others, I think you definitely need to learn LVM inside and out. And also RAID. And also good on and offsite backup strategies. And also redundant servers.

BTW, 80Gb is a huge amount of space for /var. Unless you're running a large database or other app that uses that much disk. If you're planning all that as online logfile storage, I think you might want to reconsider your plans. That's a pretty unusual setup. If you have some mandate to store that many logfiles, I would expect that that same mandate would specify they be stored securely, off site, as well.