Proper Filesystem Layout
Pages: 1, 2
Unlike /usr, the / partition usually must be mounted read/write, because it is where system configuration information, device filesystems, and
the /proc filesystem -- if it exists on your system -- reside. For some systems, it is possible to get / to the point where it does not
need to be written to, but you have to know your system very well to
do this, and it is probably not a good idea even then.
|
|
Similarly to /usr, though, good filesystem layout means you can
size your / partition very closely; on Solaris it is relatively
easy to get a / parition of only around 50 MB of data, so a 75-MB
partition will easily last the life of the server.
/home
Whether /home counts as part of the operating system or part of the
application depends on what the server is being used for. If you have
a web server that will only have administrators logging into
it, then /home can safely be included on / because it should be small
and should not change much.
But if the server will be a file server for the LAN, then /home often
becomes part of the application. You can even remove /home entirely
and replace it with NFS-mounted home directories, which may or
may not be appropriate depending on your application and network
design,
and how closely up-time is linked to the existence /home (because
NFS-mounting
/home adds another point of failure).
Application partitions
Servers are most often provisioned for a single application or service, and it is definitely preferable to do so. As such, it is usually easy and often makes sense to put that application on a separate partition. Also, many servers put the operating system on internal disks and all application data on an array of some kind, which clearly eliminates the possibility of collocating that data on the same disk as your operating system.
Applications are where filesystem layout becomes most difficult, though -- whether you have one or many, either on local disk or an array. In some cases, such as high-end databases like Oracle, the application vendor will have specific requirements as to filesystem layout, which leaves where to physically locate each partition on disk as your only decision -- that's another topic entirely. Most other applications provide much more leeway in filesystem layout, meaning your decisions are more difficult. Generally speaking, it is best to put your application on a separate filesystem from your operating system. But this is not always possible with limited disk space or many different applications, and with services such as NIS+ that use essentially no disk space there is no point in doing this.
If your application requires a lot of space,
then put that space in a separate filesystem, especially if there
will be a lot of non-logging disk access. If the application will
be doing significant amounts of logging, place the logs in /var if at
all possible, especially if that is the only real I/O the
application requires.
If you are planning on running many applications on a single server, plan to segregate them but only up to a point: If you have 50 very similar services and none of them require much space or I/O, then collocate them, but if you have 5 very different services with disparate space and I/O needs, then it makes sense to give them their own filesystems.
Some applications turn what would otherwise be operating system
filesystems into application directories, such as when an application
resides in /usr/local or when a mail server spools into /var. Some
applications prefer to be in /opt, and some
commercial Unix variants prefer to place both operating system and application
data in /opt -- this is especially true with HP-UX. In these cases, it is best to
break the application portion out onto a separate filesystem, such
as /usr/local/apache or /var/spool. If you cannot do that, treat the entire filesystem like an application filesystem
rather than an operating system filesystem. This will simplify
your backup rules and make data loss and service interruption easier
to avoid.
Sometimes makes sense to separate an application from its data. Web server configuration files and binaries don't change very often, but the data that goes with them is usually quite dynamic. Databases also often separate the application from the data. For this type of decision, you can treat the separate pieces as though they were separate applications: If they have very disparate I/O and space needs, they should be separated; but if they behave similarly, then it makes sense to keep them together.
Conclusion
Hopefully this has helped provide some basic guidelines for how to partition your all-important data. Because of the large disks most servers ship with these days, we usually don't have the space constraints that traditionally plagued system administrators, but improperly setting up a server can still come back to haunt you. More and more operating systems are also providing comprehensive volume management, which allows a system administrator to recover from poor disk-space forecasting. However, no one wants to try to resize volumes and reallocate data on a live server, and it often can only provide stop-gap solutions because of how the filesystems are laid out on disk. The absolute best aid in figuring out how to partition a system is a historical analysis of the application for which you are provisioning space, but such analyses are depressingly rare.
In the absence of a historial analysis of the system, just follow these guidelines, always pay attention to how your various filesystems will be used, and never forget that underlying it all is actual hardware -- if you ignore the hardware itself, whether in sizing, purchasing, or how you spread the partitions across it, the best filesystem layout in the world won't keep your server running smoothly.
Luke A. Kanies is an independent consultant and researcher specializing in Unix automation and configuration management.
Return to the Linux DevCenter.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 9 of 9.
-
small / bad idea
2003-02-13 13:49:22 datasmid@xs4all.nl [Reply | View]
If root dumps a big core your lean and mean / might fill up with a corefile. I've seen a 56Mb core on a 76Mb / causing serious trouble.
With a major update of your OS a tight / might ruin your day as well.
-
Disk are not faster at outer edge (?)
2002-05-02 09:38:52 aleistad [Reply | View]
In the article it is stated that: "The first cylinders of a disk -- the cylinders at the outer edge -- are spinning the fastest and thus provide the best performance..."
But, surely disks are using a constant angular velocity with an equal number of sectors per cylinder.
So how are disks "faster" at the outer edge?
-
you forgot /opt
2001-10-15 13:47:55 saintium [Reply | View]
In the Slackware, Redhat, and Mandrake distro's these days /opt is being used for Gnome and KDE and they are pretty hefty.
-
You forgot an important one...
2001-10-15 04:48:48 macemoneta [Reply | View]
Many people overlook the importance of a separate, minimal size, partition for /mnt. The reason that this is important becomes clear when using removable drives (like Jaz drives). If the mount fails (perhaps an improperly formated device being mounted by an unattended process, like a backup), the /mnt subdirectory (e.g., /mnt/jaz) is still available; data written to that directory will end up in the root ("/") filesystem, possibly leading to the failure of other processes. By creating a minimal filesystem for /mnt, the system is protected from mount failures.
Mace Moneta -
You forgot an important one...
2002-10-17 18:18:38 anonymous2 [Reply | View]
You can make the directories in /mnt read-only, it won't affect the mount operation. -
You forgot an important one...
2001-10-29 19:58:09 kanies [Reply | View]
Yes, that could be a problem, but the majority of unix servers don't use read-writable drives. Tape drives are common, but that's a raw device and won't work without the tape in the drive.
Really, the best solution to this problem is error checking--if you have a hands-off script which mounts a volume, then check that the mount worked before you start writing data to it. All scripts and programs should do error checking anyway, especially when it comes to this type of operation, and throwing away space isn't a very good substitute.
is there a script that can automatically clean it up. I have to manually get rid of stuff.
If anybody know anything, do tell.