What Are Appropriate Sizes For Linux Partitions?

stuyman asks: "I'm amazed that I haven't been able to find a good source of information on this sort of subject, but it seems that all anyone ever says is that it needs to be determined based on "certain factors" on an individual basis. No one ever says how to evaluate those factors. I need to set up a whole bunch of new Linux servers. How big should the partitions be? Anyone have any formulas or ideas? I'm open to superstitions, too (heads, root is 300, tails it's 60). Some quick details about the setup: We've got a 20.5 gig HD and we want to have separate partitions for /, /var, /usr, /usr/local (maybe), /home, /opt, and /tmp, as well as a sufficient amount of swap. The servers will run RedHat 6.2 with Apache stronghold, and will also need X installed. We're currently leaning towards having huge /usr and /usr/local, with about 2 gigs for var. Also, how much /var would one suggest for a syslogd server that'd be serving logs for 50+ boxen? (running mostly RH or SunOS) Awaiting this thread eagerly..."

Comments

RAID?

[Christopher Thomas]

My intent here was to have two 10G disks instead of one 20G disk, and partition them in a way so that if one disk failed, I could keep running essential stuff (like news, mail and the web server) on one until I could buy another. That's why each partition on /dev/hda has a corresponding partition of the same size on /dev/hdc. I have a nightly script that copies [...]

I have a similar philosophy, but just used mdtools to set things up as a RAID1 across two 13 gig drives. Everything but the root partition is on the RAID, and I made a manual copy of the root partition on the second drive. If the secondary drive dies, no problem. If the primary drive dies, I use a floppy to boot off of the secondary drive's root partition, and again no problem.

I haven't been brave enough to yank a drive to test this. I also suspect that my recovery skills aren't up to snuff; however, mdtools leaves a valid ext2 filesystem on each of the partitions, so in the worst case I can mount the valid drive's partitions as ext2 and spend several hours shuffling files to another drive, wiping the RAID drives, and reconfiguring the RAID.

Re:If You Have to Ask...

[Tet]

Also, why on earth do you want so many partitions?

This is one of the big problems with the success of Linux. All the new users are all well and good, but they don't know the reasons for doing things a certain way. Partitioning is one of those things (and is not helped by crap like Corel Linux which installs everything into a single filesystem).

Basically, partitioning should be as follows:

• Have a small root filesystem. This contains the bare essentials needed to get the machine up and running. Historically, this has been small to allow quick recovery after a crash. Once journaling filesystems for Linux become commonplace, this will be less of an issue.
• A separate /var. This filesystem holds all your variable data. You don't want a rogue process (or processes) filling up your root filesystem, so you make /var separate. The size of /var will vary depending on what the machine is used for. A typical workstation can have 200MB or less. Large servers could have several GB (and will typically have extra filesystems specifically for /var/spool/mail, /var/spool/lpd, etc.)
• If you don't give /tmp its own filesystem, make it a symlink to /var/tmp. Again, this is to prevent the root filesystem filling up.
• Make /usr big enough to hold all your commonly installed stuff, and then mount it read only. Linux systems behave badly in respect to /usr. Most 3rd party RPMs (e.g., CorelDRAW) only install into /usr, and aren't relocatable. Not only is this in violation of the FHS (which says that sort of stuff should go into /opt), but it seriously screws with resource planning. Consequently, if you plan on adding stuff via RPM, allow enough extra space in /usr. On a typical RH6.x system, a full install requires about 1.2GB for /usr, plus whatever else you plan on adding there.
• /home gets its own filesystem, again, to stop the root filesystem filling up. I personally use /usr/local/home for home directories, so I leave /home on the root filesystem, but you get the idea.
• /opt should get it's own filesystem, and should be mounted readonly. /opt is for optional extra software, typically supplied by a third party.
• /usr/local is your own place to play around in. If you give it a filesystem of its own, then, like home directories, it can be left untouched when you decide to upgrade the OS.
• I tend to have a small /boot filesystem as well, mounted read only. This isn't essential, but it has historically allowed me to have a small /boot below the 1GB limit that LILO can boot from, and put the rest of the OS wherever I wanted. Now that LILO can boot from above 1GB, it's not such an issue, but AFAIK, all the Linux distributions that use LILO still ship with the 1GB-limited version

For your 20GB drive, then, I'd have a 50MB /boot, a 100MB /, a 300MB /var, a 3GB /usr, a 3GB /home, a 6GB /opt, and whatever else is left as /usr/local. Make /tmp a symlink to /var/tmp, and you're all set. Depending on how much stuff you're planning to serve with Apache, you may want a separate filesystem for that, but only you can make that decision.

Re:My scheme

[ptomblin]

Now you've got me confused. I can't remember when I did that test if I was actually booting off that disk, or booting from a boot floppy. But even if I had to boot from a floppy, I'm pretty sure I can mount what is currently /root_shadow as /.

Ok, add one other thing to my list of what I'd change if I had to do it again - I'd make sure /root_shadow was near the beginning of the drive.

--
A "freaking free-loading Canadian" stealing jobs from good honest hard working Americans since 1997.

My scheme

[ptomblin]

It's not perfect, but it's mine:
/dev/hda1 101075 83487 12369 87% /
/dev/hda10 4408138 1827348 2352669 44% /backup_1
/dev/hdc10 4423964 4023975 171049 96% /backup_2
/dev/hda5 1981000 1255590 622998 67% /home
/dev/hdc5 1981000 619979 1258610 33% /opt
/dev/hdc9 99507 72393 21975 77% /root_shadow
/dev/hda8 101075 2195 93661 2% /tmp
/dev/hdc6 991000 767770 172026 82% /usr
/dev/hda6 1981000 420730 1457858 22% /usr/home
/dev/hda7 995115 98461 845248 10% /usr/local
/dev/hdc1 1981000 206648 1671941 11% /var/spool
/dev/hdc7 99507 306 94062 0% /var/tmp

If I had to do it over again, I'd make / a bit bigger, and maybe make another partition for /var.

My intent here was to have two 10G disks instead of one 20G disk, and partition them in a way so that if one disk failed, I could keep running essential stuff (like news, mail and the web server) on one until I could buy another. That's why each partition on /dev/hda has a corresponding partition of the same size on /dev/hdc. I have a nightly script that copies everything in / to /root_shadow (and yes, I tested that I can yank hda out of the system and boot from hdc). I also have the nightly script copy stuff into /backup_1 and /backup_2. (This is as well as backing up to tape - call me paranoid).

--
A "freaking free-loading Canadian" stealing jobs from good honest hard working Americans since 1997.

What I do...

[Wakko Warner]

/ doesn't need to be big, if all you've got in it is /etc, /lib, /bin, and /sbin. Mine's about 90 megs or so.

/usr, if you're gonna have a separate /usr/local (and you should have an /opt, by the way, for "payware"), should be a couple hundred megs.

/usr/local should be a gig or two. Especially if you're using huge bloated apps like emacs or the Gimp, which can easily chew up 60 megs alone.

/home -- make it as big as you can. I find I'm running out with 2 gigs.

/var -- if you're hosting a huge amount of mail, make it large (a gig or so). If not, don't bother. Mine's about 400 megs, and I've got plenty of room.

/tmp - I like to compile stuff in /tmp. Yes, I'm bad. A gig here for me.

Now, you need space for "other crap": mp3s, temp space for other packages, download space. I use the "sandbox" scheme:

/dev/sde1 8746648 7321200 981136 88% /sandbox3
/dev/sdd1 4307423 3763192 321312 92% /sandbox2
/dev/sdb4 1416229 1008444 334602 75% /sandbox1
/dev/sdc1 4102112 3562837 327008 92% /sandbox0

Which I stole from Northeastern's CS department scheme, just because it seemed cute. All the stuff I'm about to burn to CD, or have downloaded and want to fool around with, or that's a big lame work-in-progress that won't fit in /home goes somewhere in there.

- A.P.

--

"One World, one Web, one Program" - Microsoft promotional ad

/usr/local

[eMBee]

first, DO NOT combine /usr and /usr/local
/usr/local is very dynamic, depending on what you put on there, while /usr is pretty static.

how much you allocate for each partition mostly depends on how flexible you are and how long the system will run without adding diskspace.

/: on my redhat 6.2 disk takes about 40MB, 6.1 takes 50, i don't know why there is that difference, it is likely that i installed less stuff on the 6.2 machine, my / have a size of 70MB.

/usr: when i installed rh 6.1 i allocated 1GB for /usr, it eventually turned out that it was not enough, as i wanted a fairly complete desktop install. for your servers this will be a lot less, as you don't need all the games and stuff.
i'd suggest you make a test install of what you want to have on your system, see how much /usr needs, add 50% to have room to grow, and use that.

/home and /usr/local: these two are really individual, there is no way to generalize on those, some people do not need anything in /usr/local because they hardly compile and install their own software, others do a lot more, same for /home, it is really not to say...
i often found out that no matter what i chose, one partition ended up to small.
one way to combat that was to make sure both partitions have a different size (like 5GB and 8GB) that way, if you find that one partition was to small, and the other to large, you can exchange them, or move the larger partition to a new disk, and move the smaller to the larger one.
if you want real flexibility, combine them:
nowadays i have a large partition in /local and link /usr/local -> /local as well as /home -> /local/home
that way, it doesn't matter...

/opt: do you really need it? are you sure? well then same considerations as for /usr/local and /home, and if you want flexibility, again, combine (/opt -> /local/opt)

/var: this depends on how much data you want to keep, don't like log rotation? better make it very large, otherwise a few 100 MB should do.
but, consider mail, have lots of users? you'll need lot's of space in /var/mail
on one system (debian) we had to go as far as putting /var/mail on a seperate partition and use user quotas on it too, to make sure everybody could get their mail...
but we also had to split up the rest of /var. to make sure that in case of a full disk only a few systems are impacted, we now have a seperate /var/log (1GB) (which is only 4% full) /var/spool(1.5GB, 29%full) and the rest of /var(1GB,26% full), this is for a smaller server with about 150 users, which also just received a renewal, so the sizes are desigend for growth (the previous system had a lot less space)
the isp i work for, unfortunately opted for the "don't partition at all" approach, so i can't say anything about that (we have load balanced machines and the data is kept on raid, so the situation is different)
to make further growth easy, we have several partitions that we keep empty and hide away from the users so we can add them to the system as needed while keeping the users disciplined because they don't know about that...

/tmp: another very variable thing, your diskspace is limited, but users may temporarily need lots of it for compiles? make it large!
there is plenty of rome in /home? you don't need to worry so much about /tmp then.
want to make the best of your recources? consider combining /tmp with /var, that's what i do (/tmp -> /var/tmp), works fine.

greetings, eMBee.
--

Veritas Volume Manager

[Muck]

I used to go through the same dillema every time I setup a system, then I discovered Veritas Volume Manager! You can adjust things as you need them changed. I don't know what type of environment you're in.. but I was always in fairly small environments, and sometimes a system purpose would change drastically, 6 months after it was up. And you don't want to have to move all the data over someplace else, rebuild another file system, etc etc.. With Veritas, you can just go in and change the size of the volume (partition), and the filesystem, with just a few short keyboard clicks.. and I think it even has a nifty GUI, where you can drag and pull and stuff. Check it out at veritas.com. as to your question.. make the place you'll be storing data big.. (not sure where that will be on your system).. make the place you'll be storing binaries, not so big (a gig or so over what you need initially).. and make the partition your logs will be on huge. theres nothing worse than having your /var partition fill up at 3am...

If You Have to Ask...

[InitZero]

...You probably don't know enough about how you are going to use your system.

Also, why on earth do you want so many partitions? If each was going to be on a different drive, it would make sense to break them up. However, you write that it's all going to be on a single 20 gig drive.

On my personal systems, given how cheap disk space is now, I only have two partitions. One is root with two gig of space. Everything goes here except personal files. The other is /home where everything else goes. On a single-user system that has little in the way of new software after the initial install, this works great. (Assuming you correctly rotate logs and such.)

On production nodes, it is never that simple. The first thing you have to do is determine what partitions are static and which are dynamic. For example, /usr and /sbin are hardly ever going to change. Install them tight. On the other hand, /dbhome/oracle/data will get larger by the day. Make sure you have enough room out there for your dynamic partitions.

Of course, since you only have one drive, you may want to take the easy way out. Why not have one and only one partition: root. If you will never fill the full 20 gig and these are workstations and not servers, why have the headache? (I suggest these are workstations because X is being installed and no one in their right mind would bog down a server with X. Am I right in thinking that these are development boxes of some sort?)

I know I will get flamed for the above suggestion. Mostly from the clueless, of course, but there will also be some smart people out there who will find me insane. I hope those gurus will think twice before posting.

When you get right down to it, on a user's workstation with a single drive and no plans for expansion of the box's role, why wouldn't you keep everything in /root?

The only thing I can come up with is backups but 20-gig is small potatoes so I can't imagine that's much of a concern. Especially if the backups are incremental. (ADSM/TSM rocks!)

InitZero

Re: # of partitions...

[InitZero]

first off, for security purposes.

I'm taking these nodes to be workstations for individual users. These are, for the most part, not shared machines. Thus, while I agree with you in theory, in this practical case, you security concerns are moot.

a big screwup causes corruption of a particular partition

Good point though I can't think of a non-physical problem that would screw up a single partition given the single harddrive.

I'm not trying to be negative. I've split data across many partitions on single drives myself. I just want to know if I've been wasting my time.

InitZero