Over the course of decades, I've settled on a file system layout that doesn't match the conventional views. In particular, it tries to separate the system installation (kernel, userland, ports collection and corresponding configuration files) from the data on the system, which helps with upgrades. Here's my recommendation; see below for the rationale.

• Make a single root file system of about 20 GB.

• Make a second file system of the same size to be used for upgrades. Install upgrades to this file system, so that if anything goes wrong, you can still return to the old root partition.

• Do not create a separate /usr file system.

• Do not create a separate /var file system unless you have a good idea how big it should be. A good example might be a web server, where (contrary to FreeBSD's recommendations) it's a good idea to put the web pages on the /var file system.

• Use the rest of the space on disk for a /home file system, as long as it's possible to back it up on a single tape. Otherwise make multiple file systems. /home is the normal directory for user files.

• Create a directory /home/var and move all of /var to it with the exception of /var/run and /var/db. Remove the other directories from /var and replace with symlinks. Keep /var/run and /var/db on the root file system, since they're related to the installed system.

• You may choose to make /usr/src, /usr/obj and /usr/ports symbolic links to corresponding files on /home. That doesn't really make sense, but they're big, and an extended spate of building can easily overflow the root file system.

• Don't install anything private in /usr/local. Put it in a corresponding hierarchy /home/local instead.

This layout allows for easy backup of the file systems, and it also allows for easy upgrading to a new system version: you just need to replace the root file system. It's not a perfect fit for all applications, though. Ultimately you need to make your own decisions.

Rationale

This is an extract from The Complete FreeBSD, written in 2001, but it applies equally well to any normal UNIX installation. In that time, the sizes have changed, so the sizes in the recommendation don't quite match the sizes above. I have also refined the method a little since then, so not all of the text above occurs.

When UNIX was young, disks were tiny. At the time of the third edition of UNIX, in 1972, the root file system was on a Digital RF-11, a fixed head disk with 512 kB. The system was growing, and it was no longer possible to keep the entire system on this disk, so a second file system became essential. It was mounted on a Digital RK03 with 2 MB of storage. To quote from a paper published in the Communications of the ACM in July 1974:

In our installation, for example, the root directory resides on the fixed-head disk, and the large disk drive, which contains user's files, is mounted by the system initialization program...

As time went on, UNIX got bigger, but so did the disks. By the early 80s, disks were large enough to put / and /usr on the same disk, and it would have been possible to merge / and /usr, but they didn't, mainly because of reliability concerns. Since that time, an additional file system, /var, has come into common use for frequently changed data, and just recently sysinstall has been changed to create a /tmp file system by default.

It's relatively simple to estimate the size of the root file system, and sysinstall's value of 128 MB is reasonable. But what about /var and /tmp? Is 256 MB too much or too little? In fact, both file systems put together would be lost in the 18.7 GB of /usr file system. Why are things still this way? Let's look at the advantages and disadvantages:

• If you write to a file system and the system crashes before all the data can be written to disk, the data integrity of that file system can be severely compromised. For performance reasons, the system doesn't write everything to disk immediately, so there's quite a reasonable chance of this happening.
• If you have a crash and lose the root file system, recovery can be difficult.
• If a file system fills up, it can cause lots of trouble. Most messages about file systems on the FreeBSD-questions mailing list are complaining about file systems filling up. If you have a large number of small file systems, the chances are higher that one will fill up while space remains on another.
• On the other hand, some file systems are more important than others. If the /var file system fills up (due to overly active logging, for example), you may not worry too much. If your root file system fills up, you could have serious problems.
• In single-user mode, only the root file system is mounted. With the classical layout, this means that the only programs you can run are those in /bin and /sbin. To run other programs, you must first mount the file system on which they are located.
• It's nice to keep your personal files separate from the system files. That way you can upgrade a system much more easily.
• It's very difficult to estimate in advance the size needs of some file systems. For example, on some systems /var can be very small, maybe only 2 or 3 MB. It's hardly worth making a separate file system for that much data. On the other hand, other systems, such as ftp or web servers, may have a /var system of 50 or 100 GB. How do you choose the correct size for your system?
• When doing backups, it's a good idea to be able to get a file system on a single tape.

In the early days of UNIX, system crashes were relatively common, and the damage they did to the file systems was relatively serious. Times have changed, and nowadays file system damage is relatively seldom, particularly on file systems that have little activity. On the other hand, disk drives have grown beyond most peoples' wildest expectations. The first edition of this book, only six years ago, showed how to install on a 200 MB drive. The smallest disk drives in current production are 20 GB in size, more than will fit on many tapes.

This was written in 2001. Disks have continued to grow, and at the time of writing this web page (January 2010) typical sizes are between 500 GB and 1000 GB. All the more reason for this rationale.

As a result of these considerations, I have changed my recommendations. In earlier editions of this book, I recommended putting a small root file system and a /usr file system on the first (or only) disk on the system. /var was to be a symbolic link to /usr/var.

This is still a valid layout, but it has a couple of problems:

• In the example we're looking at, /usr is about 19 GB in size. Not many people have backup devices that can write this much data on a single medium.

• Many people had difficulty with the symbolic link to /usr/var .

As a result, I now recommend:

• Make a single root file system of between 4 and 6 GB.

  See above for modern sizes.

• Do not have a separate /usr file system.
• Do not have a separate /var file system unless you have a good idea how big it should be. A good example might be a web server, where (contrary to FreeBSD's recommendations) it's a good idea to put the web pages on the /var file system.
• Use the rest of the space on disk for a /home file system, as long as it's possible to back it up on a single tape. Otherwise make multiple file systems. /home is the normal directory for user files.

This layout allows for easy backup of the file systems, and it also allows for easy upgrading to a new system version: you just need to replace the root file system. It's not a perfect fit for all applications, though. Ultimately you need to make your own decisions.