oreilly.comSafari Books Online.Conferences.


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.

Linux Network Administrator's Guide, 2nd EditionLinux Network Administrator's Guide, 2nd Edition
By Olaf Kirch & Terry Dawson
2nd Edition June 2000
1-56592-400-2, Order Number: 4002
503 pages, $39.95

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.


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.


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.

Linux Online Certification

Linux/Unix System Administration Certificate Series
Linux/Unix System Administration Certificate Series — This course series targets both beginning and intermediate Linux/Unix users who want to acquire advanced system administration skills, and to back those skills up with a Certificate from the University of Illinois Office of Continuing Education.

Enroll today!

Linux Resources
  • Linux Online
  • The Linux FAQ
  • Linux Kernel Archives
  • Kernel Traffic

  • Sponsored by: