Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am setting up a generic Ubuntu server and am trying to figure out the (best) way to partition the machine. Again, this is just a generic one:

The default drive is 20GB.

Some guides show: Separate /home, /usr, /var and /tmp partitions

Another one suggested something like this: / 4GB /boot 512MB /tmp 1GB /home 5GB /usr 5GB /var 5GB

What is the best way to accomplish this?

share|improve this question

migrated from stackoverflow.com Apr 10 '10 at 8:38

This question came from our site for professional and enthusiast programmers.

3 Answers 3

Before this gets migrated, a quick answer: I would need a very good reason to partition something as small as a 20GB drive at all. Just use one big / partition unless you have some very specific usage pattern in mind that you haven't told us about.

Partitioning something this small only leads to nightmares: /boot to small, so kernel upgrades fail... /tmp too small, so you get random crashes... /home too small, so users become unhappy... And it's very hard to tell up front what the right sizes should be.

share|improve this answer

If it was up to me i would partition it all into one big partition mounted to / Slicing up the little 20 GB you have available will lead to problems or just makes things difficult for you in the future.

If you think you will install a new OS quite often in the future you can consider making /home into a seperate partition. During future reinstalls you can just use the same /home and everything will be there allready.

share|improve this answer

As others have suggested, splitting up 20Gb might be troublesome. It does have advantages though, particularly keeping /home and /tmp separate so running out of space on one doesn't affect elsewhere.

I suggest keeping the drive as one partition, and using LVM to split thing up. That way it is relatively easy to rearrange later if you find you made something too small. Leave a small amount unallocated so that you have a quick resize option for an emergency - you can increase the size of a logical volume and resize the filesystem on it while the system is live (assuming the chosen filesystem and tools support this - I've done it with ext3). This alleviates the pressure of having to get the choice exactly right in such a small place (you just need to get it "right enough for now"), and gives you an easy upgrade option too: if you find a VM needs more space rather than just rearranging the existing allocation you can ad a second vdisk (you'll need to down the VM for this part), mark it as a pv for lvm, add it to the main volume group, and can then expend volumes into it (all this can be done live).

There is a small performance hit with LVM in many cases as you are adding an extra level of indirection to disk access but this is generally very small, so small as to not be noticeable and well worth the extra convenience LVM can offer.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.