LinuxDevCenter.com
oreilly.comSafari Books Online.Conferences.

advertisement


Proper Filesystem Layout

by Luke A. Kanies
10/11/2001

There are two main schools of thought when it comes to filesystem layout: One group says it's best to segregate as much as possible, putting everything on its own filesystem; the other group says that one should have only one or two filesystems, putting everything together on communal filesystems.

The goal of this article is to convince you to fall somewhere in the middle. Increasing or reducing the number of filesystems on a server is often a good idea, but should only be done for legitimate reasons.

General notes

Having a small number of filesystems is usually a good idea for a number of reasons. Somewhat trivially, it means fewer filesystems to monitor for free space. It also provides more leeway for sizing mistakes, because if everything is broken out into separate filesystems and you were incorrect in your forecast of how much space each filesystem would need, you might find yourself in the unhappy circumstance of having a nearly full filesystem on a server which also has a several nearly empty ones.

Speaking of filesystems filling up, this is one of the reasons for increasing the number of filesystems: Some forms of Unix behave very badly when certain filesystems, such as /tmp and / fill up. Separating these filesystems from directories which tend to grow, such as /var, can save you a lot of headaches. Aside from the operating system, when filesystem gets full, it generally means something will stop working correctly because an app is locked waiting to write data, or logs or other data cannot be written and thus are lost.

In laying out both your operating system and your application filesystems, there are a couple of factors you should always keep in mind. Probably the most important of these is backups. It is unlikely that you are designing a server that doesn't need some kind of backup, and proper filesystem design can greatly simplify the process. Some backup software can only backup entire partitions, which makes your granularity on backup rules relatively large. If you need a tighter granularity for backups, the only way to achieve that might be to break your data into separate filesystems.

It isn't immediately obvious, but filesystem layout can also have a significant impact on system performance. The first cylinders of a disk -- the cylinders at the outer edge -- are spinning the fastest and thus provide the best performance, but you also need to keep in mind the parts of the disk where the disk head will spend the most time.

If your system uses a lot of swap, which is usually the second partition, and you have a filesystem that does a lot of reads and/or writes in the last partition on the disk, then your disk head will constantly be shuttling back and forth across your disk, ignoring all of the data in the middle, but working madly at the edges. This will seriously degrade your server performance and should be avoided at all costs.

Operating system filesystems

There are five main system filesystems, which we can cover relatively easily because the guidelines on how to partition them don't change much from system to system. These are /, /usr, /var, /tmp, and /home.

/tmp

It is easiest to discuss /tmp, because it is most often a virtual filesystem stored in unused swap and contains only transient files. As such, you are not losing any real disk space, and data integrity isn't so important. However, because most systems set /tmp to be as large as the entire swap allotment, filling /tmp generally means running out of swap space, and this is a very bad thing. At least some systems, such as Solaris, allow /tmp to be restricted to a size smaller than swap, which can save you from application outages and server reboots.

/var

It is also relatively easy to lay out /var, because it will always grow and thus should be placed at least somewhat apart. Including /var on another partition, such as /, can have disastrous consequences when an app has serious problems or there is a hardware failure, because gigabytes of logs can be generated very quickly. Filling /var just means you can't log anymore, but filling / can mean service interruptions.

The most difficult aspect of /var is sizing, because it is often difficult to forecast how much log space you will need. In these heady days of 9-GB disks being considered small, you should start with a 1-GB /var partition and go up from there. For a web or email server with a lot of logging, you probably want significantly more. In fact, if you find yourself with extra space after partitioning a system, it is probably a good idea to throw that space into /var. Space on /var can also be saved by using a network logging server to store your logs.

/usr

In this case, /usr may or may not include /usr/local. Most open-source Linux systems depend heavily on /usr/local, but many commercial Unix variants use it sparingly or not at all. What makes /usr unique is that it is composed entirely of extremely important files that will only be modified during an upgrade or a patch application. If your use of /usr/local fits this bill, then include it with /usr, otherwise consider separating it.

In general, the only good reasons for separating /usr are either that your / partition has all of your apps on it or, my favorite reason, you want to mount it read-only for security reasons -- after all, most of the files modified by a root kit reside in /usr. If this does not suit your needs, then either include it on / or with /usr/local, depending on the characteristics of your installation. One benefit of separating /usr from everything else is that you can size it very closely, leaving only about 15 percent for upgrade/patching room because it is very unlikely to grow.

/

Although it is tempting to think of / as the catch-all filesystem and make it large enough to handle that duty, you might find it more appropriate to make it small. Application filesystems will be discussed later, but without /var or /usr, / is now relatively small. In fact, one of your goals when sizing the root partition should be to keep it as small as possible, hopefully under 100 MB. Because the major components of / are /etc, /dev, the kernel, and some statically linked binaries, this should be relatively easy to accomplish.

Pages: 1, 2

Next Pagearrow




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.java.net
  • Linux Kernel Archives
  • Kernel Traffic
  • DistroWatch.com


  • Sponsored by: