Proper Filesystem Layout
by Luke A. Kanies10/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 |
