Linux partitioning and mountpoints

[derekzeanah]

Partitioning a system used to be a pain in the butt because of the thought you had to put into filesystem layout -- how much space should be in /var for mail files (and does this distro use /var for mail, anyway? Are my MySQL databases going to be here as well?), /home for the random stuff you throw in your account, /root and /boot, /usr/local (is this something to worry about with this distro, anyway?), and so on.

It worse when you're partitioning a system to throw in a datacenter to live for a few years -- I've got a system now that's running out of space on some partitions, but greater than 40% of the original space is still available, it's just partitioned in a way that isn't terribly useful for my current deployment.

Soooo, I was installing a new machine using CentOS 4.4 the other day, and noticed that they take the lazy approach and throw most of the space on the drive into a huge / partition.

My question is this: is there a reason to manually partition any more? The most compelling one I can think of is having a small partition you can mount in case the filesystem gets hosed and you need to fsck it, but using EXT3 (and its journal so yanking the power cord out of the wall doesn't mess up the FS like it used to) and hardware RAID (to get rid of the problem with random FS corruption due to a slowly failing SCSI drive) have eliminated this as a concern for me.

What other issues should I be looking at?

 

[n0cmonkey]

Server: YES
Desktop: probably not
Workstation: depends

EDIT: Leave some unpartitioned space at the end of the drive for tweaking.

 

[BurnItDwn]

You probably thought of this, but forgot to mention it ...

What about the situation where a specific file grows MUCH larger than normal and fills the filesystem.

for instance, a log file in /var ....
Would you rather deal with just a full /var filesystem .... or the entire / filesystem being at 100% ???

Granted if your var filesystem is 100%, nothing will be able to write to the logs there really, however, there is still a lot less impact than / and * under it.

 

[Nothinman]

Would you rather deal with just a full /var filesystem .... or the entire / filesystem being at 100% ???

Either would be fine, / getting full won't cause the system to panic or anything.

Personally, I've always thought people over did it with the mount points on most systems. I can understand seperating /var if you're going to put MySQL or PGSQL data there and /usr/local if you plan on compiling anything by hand and putting it there so that you can be sure it won't be touched on upgrades and such. And of course /home is good to seperate if users will have accounts on the box. But that's about it.

And if you use LVM you'll be able to shuffle space around more easily, just make sure you use a filesystem that can be shrunk like ext3.

 

[sourceninja]

I've always separated /var, /user/local/, /home, and /tmp.

Var on its own partition has saved me just recently when our apache log became about 15 gigs when the auto rotate script somehow got removed from cron. The var partition filled up, I'd hate to think of what would of happened if that had not been on it's own partition. We would not of caught the problem until much much larger.

 

[Nothinman]

he var partition filled up, I'd hate to think of what would of happened if that had not been on it's own partition. We would not of caught the problem until much much larger.

Nothing at all, at least nothing terribly bad. You couldn't be able to write to anything directly on /, so you probably couldn't update any packages, but since /tmp was also it's own filesystem that's about it. /, /usr, /etc, etc aren't written too very often so you'd only notice the failure when doing something out of the ordinary or since /var was a part of / you'd notice when the logs weren't being updated any more.

 

[BurnItDwn]

Originally posted by: Nothinman

he var partition filled up, I'd hate to think of what would of happened if that had not been on it's own partition. We would not of caught the problem until much much larger.

Nothing at all, at least nothing terribly bad. You couldn't be able to write to anything directly on /, so you probably couldn't update any packages, but since /tmp was also it's own filesystem that's about it. /, /usr, /etc, etc aren't written too very often so you'd only notice the failure when doing something out of the ordinary or since /var was a part of / you'd notice when the logs weren't being updated any more.

a full /etc or /usr mean generally none of the services or servers would run out of temp space or have problems ...
If /etc or /usr were on the main / partition, along with /tmp and /var .... then you'd have problems where services failed .. downtime is bad.

Also, as far as noticing goes ... you want it so that the "users" never need to notice ...

there should be crontabs set up to contact people when filesystems start to get full ... (I say people, because often times sysadmins support the box while an app group or another group may support all the code on another file system. If the app group fills up their app file system, it shouldn't impact anything else on the box, and the admin group shouldn't need to be bothered by it ...)

For servers, especially enterprise level production servers, it's really important to split up the filesystems.


For other systems, it is not nearly as important, and the extra time and effort that goes into pre-planning and then resizing in the future may not be worth it vs just using one or several filesystems.

 

[drag]

I think that when your root file system gets full you may run into a error that remounts it read-only. But not always.


I think that if I felt that I needed many mount points for the various /home, /tmp, /var or whatever I wouldn't use partitions. To much a PITA.

I'd rather have LVM, and use logical volumes for servers and such. That way you can dynamicly allocate storage space as you need it instead of guessing what you need at install time.

 

[Nothinman]

If /etc or /usr were on the main / partition, along with /tmp and /var .... then you'd have problems where services failed .. downtime is bad.

Depends on the service, a lot of services run just fine without adding new data besides logs and won't fail even if the logs are full. Obviously it's not good to lose those logs, but it wouldn't result in downtime. They may not restart if they can't create a pid file or something, but if they're already running they'll probably be fine.

For servers, especially enterprise level production servers, it's really important to split up the filesystems.

But not necessarily in the way the OP described. You can put your databases, mail spools, etc wherever you want. A good example is the last company I worked at, they had a policy if putting all of the locally installed daemons and their data under /local. So having /, /var or whatever fill up wouldn't affect them at all.

I think that when your root file system gets full you may run into a error that remounts it read-only. But not always.

No, that's only for internal filesystem errors and it depends on the filesystem. ext3 lets you specify how it handles errors in fstab and XFS will just freeze the filesystem. I don't know how any others react, reiserfs probably kills your cat or something.

 

[silverpig]

I have one large /home partition as I put my downloads etc there as well as whatever large files I'm working on at the time. I also have a ~15 gig / partition for everything else. It works well because I occasionally switch distros just for fun and all of my personal stuff is still there.

 

[drag]

One fun one to take a look at is setting up /usr/local/ on a NFS or SMB share or something.

That way you can mount it on multiple computers and if you install compiled software or third party software to /usr/local you can have it aviable on multiple computers at once.

Most distros correctly setup the environmental variables for using /usr/local, but you can use /opt or other ones if you feel like it (I like to setup a ~/apps shared directory for single users). I like to do this with games and other such thing.