Dear All,
We are about to build a new centos machine and have seen previously that this /var could grow due to many log and even the mysql db in it. So what is the best way to handle it create a separate partition or increase its size will do? Thank you.

Yes, best choice. /var holds logs and important system run records; moreover, it often house some /tmp directories peculiar to DE's, so it can reasonably grow, especially if running as a server.

Regular desktop eats between 800Mb to 1.5 GiB of space for /var. So, if you want to make sure not to overrun the size you may create a partition for /var about 2-3GiB.

Should consumption increase as to exceed that partition space you can remedy by moving that voracious tmp file to another spacious partition and leave only a link in the original /var location; (I have done this many times with mine) -- There are many ways of working it around though.

It is not arbitrary for the user to increase or decrease usage of /var/tmp; this is a work space for some important libraries. If you expect your system will use /var extensively then mount it to a sizable partition.

Welcome.

Dear Malek,
Well we have encounter before the log files even cross 50Gb so wondering if we allocate it 100Gb where it houses mysql server too. Will that be a good and safe choice. What are the other folders which can be eating up the hard disk ? Is it good to keep /tmp also on separate partition? IS there any security vulnerability if we keep them on separate partitions?

I have overlooked your declaration that you will house the mysql database there; so, if that's the case you'd better prepare a bigger volume commensurate to the size of database expected.

W/usr should be enough to contain all libraries, binaries, documentations, etc.


Yes, for in doing so you can impose permissions at mounting the /tmp partition.

Dear Malek,
For example when I run this command fdisk -l I get this . So when I do partition each will be shown separately I guess rite. What does this represent /dev/mapper/VolGroup-lv_? What is the VolGroup here? So how big should I keep the /usr folder? What is the security permission I should impose on /tmp and how big this size should be? Say I got a 250Gb hard disk can I give 150 gb to /var and /5gb to /usr and 5gb to /tmp?

It depends on what the machine is doing. /tmp can be a hog. When you watch a youtube video it hogs space in /tmp (depending on version of flash). When I edit an audio file in audacity it makes copies of each track in /tmp. And I do 24bit/192kHz recording of hour plus concerts, so 4GB per copy, and each edit creates an additional copy for undo history.

In debian /var also hosts /var/cache/apt/archives/ which is where all of your packages get downloaded to when you do the inital install and each update there after. You can generally purge these safely, but you have to know they exist first. And /usr/share/doc/ can be a real hog of mostly unused stuff. At least from a desktop orientation where every available thing is installed even if most of it never sees a cpu cycle after the install.

As I look at my fresh debian sid install of < 1 weeks use and already just shy of 9GB of space. And Gnome or KDE isn't even installed (using IceWM). With 1.3GB of debs in the archive and 0.9GB in /usr/share/doc/ and 2.7GB in /home/. /home breaks down to 1GB in game/browser cache + 1.1GB in video driver files(--keep), which isn't really much in user files yet. For someone who records and edits video and audio. Fortunately I still have 39GB elbow room with the current setup. Which would imply that I still have 30GB of cruft to sort through from the previous install on this same device and location.

Dear Shadow,
My usage is on centos 6.2 mainly for mysql server and apache server. With that in mind do you think I should make a bigger /tmp?

Only one way to know that. Is to use it and see what works. If you're already using it, you might want to monitor it too see what it's typical usage is during peak hours for your purposes. From my experience, /tmp seems to have taken on the role that swap used to take. Except that it's treated directly as temporary storage space instead of RAM that doesn't exist. And most things that use it for anything size-able seem to be expecting sizes that they already know will NOT fit in RAM. Does that mean use the old 2*RAM rule associated for swap space, I do not know. But it's always good to have too much than too little.

1. you need to look at current usage and go from there. Each system is different, A separate partition for /var may be a good idea.
Also consider putting the DB on its own partition.
2. maybe you need to make logrotate more aggressive; adjust your backup system to match so you don't lose anything.

Dear Chirsm,
So if I set the db for its own partition I must set from the mysql settings right? Another thing will partition be good idea to maintain the harddisk space? For the tmp I think I will go with the idea from Shadow_7.

From a performance perspective you might want the DB to be it's own device. And not just a partition. If you're still on spinning platter storage medium, there's a performance costs to move the read heads back and forth between partitions. It does not "have to" be, depending on usage. But things that are going to abuse a device (heavy reads / write) like a database or logging, you'll want to point at a different device to manage wear and tear. Plus that makes backing up and long term maintenance easier.

Dear Shadow,
Yes this machine is going to be dedicated just for the db. So what else to do because I am sure there will be heavy read/write because it is the db server. So what type of backing is suggesting like for mysql I see there is tools from percona. Based on your experience what are key steps normally taken to avoid disasters?

Disaster, redundancy, resiliency, performance options; backups, RAID, clusters, replication.
See also the innodb_file_per_table option.

Dear Christmas,
So far tried to implement replication and also innodb_file_per_table. Will look into your other options too.