Proper Filesystem Layout
Pages: 1, 2
/ partition usually must be mounted read/write, because it is where system configuration information, device filesystems, and
/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.
Linux Network Administrator's Guide, 2nd Edition
/usr, though, good filesystem layout means you can
/ 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 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
/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
becomes part of the application. You can even remove
and replace it with NFS-mounted home directories, which may or
may not be appropriate depending on your application and network
and how closely up-time is linked to the existence
/home adds another point of failure).
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
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
/usr/local or when a mail server spools into
applications prefer to be in
/opt, and some
commercial Unix variants prefer to place both operating system and application
/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
/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
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.
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.
2010-05-13 10:52:34 unconscious [View]
2004-10-01 09:32:32 hpbox [View]
small / bad idea
2003-02-13 13:49:22 email@example.com [View]
2002-12-30 11:26:48 anonymous2 [View]
Disk are not faster at outer edge (?)
2002-05-02 09:38:52 aleistad [View]
you forgot /opt
2001-10-15 13:47:55 saintium [View]
You forgot an important one...
2001-10-15 04:48:48 macemoneta [View]