Linux Server Partitioning Guidelines

[giantmidget 0]

Sup everyone! This is my maiden post. I've actually followed binrev radio for the last two years. Also, I'm in PHX.

Here' s my question:

Can someone tell me or point me to some good rules to follow when setting up partitions

on a Linux server? IE. How big should the root partition be and why? Etc...

Thanks

GM

[s0u1d13r 0]

I never really have a magic number that I use, and it varies. You don't necessarily have to worry a HUGE amount on how big the root partition is unless swap allocation becomes an issue.

Your root partition will generally hold all your data and the swap space is used for virtual memory, like virtual RAM (for lack of better terminology).

If you are running some rediculously fast machine, with a fat hard drive, just use the defaults for your distro. If they don't ask for root partition size tell it to use as much as possible.

Generally the notes/docs for your distro will give you the best idea on what to use for partition benchmarks depending on hardware.

S

[Dr^ZigMan 1]

There have got to be at least a million different ways of doing this... Personally (meaning me, and if you don't like my way ) I tend to lump everyting together. For a 40 gig hard drive with a gig of ram I set up a swap of 2 gigs and the rest as just a root partion. However some people will recomend you set up a seperate boot partion, but I've never used that rule of thumb. What I'm basically getting at is don't over partion your drive, if you do you'll always run out of space on the one drive your trying to add to!

Anyone else have any ideas/suggestions?

-Dr^ZigMan

[oneeyedelf1 0]

in a server enviroment, all big major applications that can be chrooted, should. And that all those should be on a seperate partion. Also deffinatelly keep your tmp files and your log files on a different partion to help maintain linerality. DB files should also be on a different partion.

[LogosX 0]

The last I read about this was from dual_parallel and bland_inquisitor, heres the artucle.

I usually do a full bloated install of the distro, with two partitions / and swap, then based upon the size of the folders thats how big I make each partition.

[luminaire 0]

The best guide for partitioning is use Linux/Unix for a while with a general purpose layout (default even) and get the hang of it. Once you've found out were stuff generally ends up ie: mail spools in /var/spool/mail then you'll know for your office mail server you MIGHT want to dedicate one fast drive, or a large partition of your faster HD to /var. If its a web server with it's doc_root at /usr/local/www/data then you might want to have an entire fast drive for /usr/local/www/data. It's totally your decision, however the best idea is to get a feel for where things end up on a drive, and watch how much space they are using, both with df -h, and du. Remember, if you run out of space you can always resize or migrate, so nothings permanent.

[iNSEM 0]

For a *nix server you should have multiple parititions for most data points on the file system. Generally I do the following:

Filesystem Size Used Avail Use% Mounted on

/dev/hda1 16M 5.6M 8.9M 39% /boot

/dev/hda2 342M 218M 107M 68% /

/dev/hda3 15G 8.1G 6.0G 58% /home

/dev/hda5 2.3G 371M 1.9G 17% /var

/dev/hda6 137M 4.1M 126M 4% /tmp

/dev/hda7 919M 816M 57M 94% /usr

It's important to do this so you can have corruptions of portions of your hd without it affection the entire system. Also if you run out of space in a particular mount point it wont affect everything else on the system.

/boot needs to be small because it only holds your kernel, system.map and if you use GRUB those config files for it.

/home is where we make all users web space, and it is where everyone subsequently stores their data. If we run out of space in /home it wont affect mail, logs, mysql data which is stored in /var (on a debian system). We keep our http root in /home with a specific user and keep all of it's logs there as well. In case someone attempts to something to Apache and it creates excessive logs, it wont overflow to anything.

/var is for mysql, mail, logs etc etc.

/tmp so we our tmp files dont become too many and take space away from var and home.

/usr holds the src dir and applications. this doesn't really every change in size on a server. You have all the apps you need installed and your kernel src's there. Again helps keep things seperate.

The above drive is about 20gigs. Just remember: most of your space should go to /home, then to /var. And the least amount to /boot. This works well for us and should for you as well. ALSO, use a journal file system. If for some reason the box restarts, power goes out, power supply issues etc, you want it to be able to skip the fsck on boot so your services come back. ext3 performance is fine for even the most traffic entensive systems and it builds on the stability of ext2 by just adding journaling.

[j4mes 0]

What kind of server?

I usually split /boot, /var, and /tmp. Everything else is up to you.

[notyourtim 1]

I've run servers only for home use. My goal is to avoid having to deal with full partitions, so I try to have a small number of big partitions. If I was running a real site on the Intarweb, I might put tmp, logs, or major applications in different partitions to prevent any one of them from hogging the whole disk. But I've shot myself in the foot doing that too many times in the past---making partitions that eventually turned out to be too small for my needs, while other partitions turned out to be too big and largely wasted. So this is my plan for dealing with my own lack of experience:

swap = 2 * physical RAM. I think I got this rule of thumb from a BSD/OS manual back in the day.

I like to keep the system programs and configuration in its own partition so that it doesn't get written to very often and will consequently survive crashes better. In theory I could also mount it read-only except during software upgrade, but I never bothered. So I make:

/ = 2GB. I've found that I usually install about 1GB of software of the distro CD-ROM. I give the partition an extra GB for future software installs.

/var = everything else. I then do these symlinks:

/home -> /var/home

/tmp -> /var/tmp

So the idea is "/" is the mostly-read-only system binaries, libs, and configuration, and "/var" is everything that has to be read and written.

Again, I'm not a real sysadmin, so YMMV.

[luminaire 0]

I've run servers only for home use.  My goal is to avoid having to deal with full partitions, so I try to have a small number of big partitions.  If I was running a real site on the Intarweb, I might put tmp, logs, or major applications in different partitions to prevent any one of them from hogging the whole disk.  But I've shot myself in the foot doing that too many times in the past---making partitions that eventually turned out to be too small for my needs, while other partitions turned out to be too big and largely wasted.  So this is my plan for dealing with my own lack of experience:

swap = 2 * physical RAM.  I think I got this rule of thumb from a BSD/OS manual back in the day.

I like to keep the system programs and configuration in its own partition so that it doesn't get written to very often and will consequently survive crashes better.  In theory I could also mount it read-only except during software upgrade, but I never bothered.  So I make:

/ = 2GB.  I've found that I usually install about 1GB of software of the distro CD-ROM.  I give the partition an extra GB for future software installs.

/var = everything else.  I then do these symlinks:

/home -> /var/home

/tmp -> /var/tmp

So the idea is "/" is the mostly-read-only system binaries, libs, and configuration, and "/var" is everything that has to be read and written.

Again, I'm not a real sysadmin, so YMMV.

←

I've always had problem only assignin the root partition only 2gb's, but that not to say that it wouldn't work. Is there any reason that your home folders are on your /var parition, and why you create symlinks to make it look like they're not? Once again, it's highly situational, so the only good advice that can be given is regarding swap, and there are still many things to consider, such as actual need for swap (having 1 gb of RAM doesn't mean you ened 2 gb of swap). Partitions schemes in unix are highly flexible, and thus can be made to suit your needs very easily, and can also be easily modified. My suggestion remains for any beginer: Use the default layout the first time, and then modify the parition scheme to suit your needs. If you discover you need more space, or a dedicated drive you can add it on. Record you changes if you are forgetful because at some point you will probably have to make another server/box like this one.

[notyourtim 1]

Is there any reason that your home folders are on your /var parition, and why you create symlinks to make it look like they're not?

←

I wrote the symlinks as they'd appear in ls output (link -> target) not as you'd type them as arguments to ln -s (target link). That probably was confusing. So without the symlinks, the contents of /home would land in my / partition. After replacing the directory /home with a symlink named "home" pointing to /var/home, the data lands in the /var partition. My goal was to put the stuff that gets written often in /var, and leave / for the stuff that is mostly read-only.

As for swap, you're right, 2*RAM is probably pretty silly advice these days now that machines have so much RAM. My servers were all old UNIX workstations with only 128 or 256MB of RAM.

I'll just creep back to the nursing home now...

Edit: I had Debian GNU/Linux systems in mind when I typed the above advice. User home directories live in /home by default on those systems. Perhaps they live in /var/home on BSD systems? I have a vague memory that I may have started doing the symlink thing when I moved to GNU/Linux from BSD/OS, because BSD/OS had been that way... not sure.

Edited August 14, 2005 by notyourtim

[Beave 5]

Is there any reason that your home folders are on your /var parition, and why you create symlinks to make it look like they're not?

←

I wrote the symlinks as they'd appear in ls output (link -> target) not as you'd type them as arguments to ln -s (target link). That probably was confusing. So without the symlinks, the contents of /home would land in my / partition. After replacing the directory /home with a symlink named "home" pointing to /var/home, the data lands in the /var partition. My goal was to put the stuff that gets written often in /var, and leave / for the stuff that is mostly read-only.

As for swap, you're right, 2*RAM is probably pretty silly advice these days now that machines have so much RAM. My servers were all old UNIX workstations with only 128 or 256MB of RAM.

I'll just creep back to the nursing home now...

Edit: I had Debian GNU/Linux systems in mind when I typed the above advice. User home directories live in /home by default on those systems. Perhaps they live in /var/home on BSD systems? I have a vague memory that I may have started doing the symlink thing when I moved to GNU/Linux from BSD/OS, because BSD/OS had been that way... not sure.

←

In server enviroments, I typically partion out the drive as others have stated (/boot, /tmp, var,

etc). One thing that should be noted: mounting things like tmp, home, etc. with the

nodev and nosuid flags in your fstab isn't a bad idea either.

[tehbizz 2]

Symlinking /home to /var/home is rather confusing since you say you want root to stay mostly read-only....then why not just put home on a separate partition in the first place? Or how about a separate drive? This avoids making weird ass symlinks.

[notyourtim 1]

then why not just put home on a separate partition in the first place?

←

As I explained in my original post, I wanted to reduce the number of partitions. I had run into problems with paritions filling up on earlier servers. For example, I had one server with separate /home and /var paritions, and I managed to fill up my /home partition while /var was still mostly empty. Putting the user home dirs in /var/home frees me from the need to guess how big "home" should be relative to "var", since they're the same partition. Again, as I explained in my original post, the goal of my partitioning scheme was to overcome the problem of me being really bad at guessing proper partition sizes ahead of time. If you have a different goal, you may want a different scheme.

This begs the question, "why not just have swap and one big data partition?" I kept / and /var separate because of the read-only, read-write issue.

Or how about a separate drive?

←

Yeah, I used to provide a separate drive for /home when I had hardware capable of supporting more than one drive. I used to use a pair of half-height SCSI-1 drives in external cases scrounged from long-dead Macs, and one of them was /home, for example. But as the years went on, the old drives wore out. I was getting them used to save money, and eventually I noticed it would be more cost-effective to just buy new IDE drives. My last "server" machine was a Sun Ultra 5, and if you want to put more than one hard drive in it, you have to remove the CD-ROM. I needed the CD-ROM, so I was stuck with only one drive.

I say "was" an Ultra 5 because it got fried during a big thunderstorm earlier this month, leaving me with no server at all for the time being.

[tehbizz 2]

OK I totally missed that part of the explanation (I wasn't terribly coherent when I was typing up my first reply). Sorry for my stupidness.

[notyourtim 1]

OK I totally missed that part of the explanation...

←

No problem, I've done that sort of thing, too.