[CentOS] CentOS 6 Partitioning Map/Schema

Thu Sep 1 09:43:01 UTC 2011
Peter Kjellström <cap at nsc.liu.se>

On Thursday, September 01, 2011 03:21:25 AM Jonathan Vomacka wrote:
> Good Evening All,
> 
> I have a question regarding CentOS 6 server partitioning. Now I know
> there are a lot of different ways to partition the system and different
> opinions depending on the use of the server. I currently have a quad
> core intel system running 8GB of RAM with 1 TB hard drive (single). In
> the past as a FreeBSD user, I have always made a physical volume of the
> root filesystem (/), SWAP, /tmp, /usr, /var, and /home. In the
> partitioning manager I would always specify 10GB for root, 2GB or so for
> SWAP, 20GB var, 50GB usr, 10GB /tmp, and allocate all remaining space to

I don't think the above figures are bad. Then again the CentOS default (/boot 
+ /) and then adding your /home may be more flexible. After that, if I split 
it further, I'd make a stand alone /var and maybe /tmp. Splitting /usr from / 
seems like more trouble than it's worth to me.

Also I'd use LVM for everything but /boot and leave some unused space in the 
VG that I could use for lvextend + resize2fs later.

Just my take on it.

> my home directory as my primary data volume (assuming all my
> applications are installed and ran from my home directories). I was
> recently told that this is an old style of partitioning and is not used
> in modern day Linux distributions. So more accurately, here are my
> questions to the list:
> 
> 1) What is a good partition map/schema for a server OS where it's
> primary purpose is for a LAMP server, DNS (bind), and possibly gameservers
> 
> 2) CentOS docs recommend using 10GB SWAP for 8GB of RAM. 1X the amount
> of physical memory + 2GB added. (Reference:
> http://www.centos.org/docs/5/html/Installation_Guide-en-US/s1-diskpartition
> ing-x86.html). I was told this is ridiculous and will severely slow down
> the system. Is this true?

Disclaimer: the following is based on CentOS-5 and I'm not 100% if all or any 
applies to the CentOS-6 kernel.

* Some swap (as opposed to no swap) seems to increase system stability under 
OOM conditions (depeding on a lot of factors)

* You'll need at least as much swap as the max stack size you intend to set 
(ulimit -s). Usually this is very low but in some instances you need a 
significant percentage of your RAM size. An alternative is to set max stack 
size to unlimited when needed (which _does not_, thankfully, require an 
infinite amount of swap...).

Based on this I'd say just add some swap (like a gig or two) unless you know 
you want a high max stack size.

If you left space in your VG you can always add another chunk of swap later.

> If so, what is a good swap space to use for 8GB
> of RAM? The university of MIT recommends making MULTIPLE 2GB swap spaces

This shouldn't really make much difference. Long ago swap size was limited to 
2G but I don't even remember if that was per swap or in total.. Either way you 
can have 5x 2G or 1x 10G. Linux will balance its usage over all available 
swaps so if you have several independant drives then use swaps on both for 
maximum performance (although it's my feeling that if you need swap 
performance then you're probably doing something wrong...).

> equaling 10GB if this is the case. Please help!
> 
> 3) Is EXT4 better or worse to use then XFS for what I am planning to use
> the system for?

Much has been said here. I'd stay with the dist default unless I had specific 
reasons. If you need >16T you have to use XFS. If you're on 32-bit you have to 
use ext*.

If you're trying to decide based on performance then try it out on your 
hardware (where preferably "it" is close to your actual work load).

/Peter
 
> Thanks in advance for all your help guys
> 
> Kind Regards,
> Jonathan Vomacka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.centos.org/pipermail/centos/attachments/20110901/d3da6121/attachment-0004.sig>