On Monday, 5 July 2004 at 23:54:05 -0400, epilogue wrote: > On Tue, 6 Jul 2004 11:41:44 +0930 > "Greg 'groggy' Lehey" <[EMAIL PROTECTED]> wrote: > >> 100 MB should be plenty of space for the root file system assuming >> that you have separate /usr and /var file systems (not something that >> I recommend, but that's what the handbook recommends). > > hello greg, > > apparently, determining how 'best' to partition a drive is a bit of an art. > because i followed the advice given in the handbook, i found my > curiosity piqued by your comment. i was wondering if you would be so kind > as to share the reasoning behind your stated view?
Sure. It's stated in more detail in my book "The Complete FreeBSD", so I'll quote that. You'll note that I recommend a root file system of between 4 and 6 GB. That's what I wrote at the time; nowadays, I think 8 GB might be a better value. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers.
What partitions? ________________ In this example, you have 20 GB of space to divide up. How should you do it? You don't have to worry about this issue, since sysinstall can do it for you, but we'll see below why this might not be the best choice. In this section we'll consider how UNIX file systems have changed over the years, and we'll look at the issues in file system layout nowadays. 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. This is what sysinstall does if you ask it to partition automatically: [Omitting PostScript image images/disk-label-default.1.ps 4i ] Figure 5-9: Default file system sizes 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: o 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. o If you have a crash and lose the root file system, recovery can be difficult. o 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. o 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. o 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. o It's nice to keep your personal files separate from the system files. That way you can upgrade a system much more easily. o 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? o 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. 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: o 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. o Many people had difficulty with the symbolic link to /usr/var. As a result, I now recommend: o Make a single root file system of between 4 and 6 GB. o Do not have a separate /usr file system. o 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. o 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. How much swap space? ____________________ Apart from files, you should also have at least one swap partition on your disk. It's very difficult to predict how much swap space you need. The automatic option gave you 522 MB, slightly more than twice the size of physical memory. Maybe you can get by with 64 MB. Maybe you'll need 2 GB. How do you decide? It's almost impossible to know in advance what your system will require. Here are some considerations: o Swap space is needed for all pages of virtual memory that contain data that is not locked in memory and that can't be recreated automatically. This is the majority of virtual memory in the system. o Some people use rules of thumb like ``2.5 times the size of physical memory, or 64 MB, whichever is bigger.'' These rules work only by making assumptions about your workload. If you're using more than 2.5 times as much swap space as physical memory, performance will suffer. o Known memory hogs are X11 and integrated graphical programs such as Netscape and StarOffice. If you use these, you will probably need more swap space. Older UNIX-based hogs such as Emacs and the GNU C compiler (gcc) are not in the same league. o You can add additional swap partitions on other disks. This has the additional advantage of balancing the disk load if your machine swaps a lot. o About the only ways to change the size of a swap partition are to add another partition or to reinstall the system, so if you're not sure, a little bit more won't do any harm, but too little can really be a problem. o If your system panics, and memory dumping is enabled, it will write the contents of memory to the swap partition. This will obviously not work if your swap partition is smaller than main memory. Under these circumstances, the system refuses to dump, so you will not be able to find the cause of the problems. The dump routines can only dump to a single partition, so you need one that is big enough. If you have 512 MB of memory and two swap partitions of 384 MB each, you still will not be able to dump. o Even with light memory loads, the virtual memory system slowly pages out data in preparation for a possible sudden demand for memory. This means that it can be more responsive to such requests. As a result, you should have at least as much swap as memory. A couple of examples might make this clearer: 1. Some years ago I used to run X, StarOffice, Netscape and a whole lot of other memory-hungry applications on an old 486 with 16 MB. Sure, it was really slow, especially when changing from one application to another, but it worked. There was not much memory, so it used a lot of swap. To view the current swap usage, use pstat. Here's a typical view of this machine's swap space: $ pstat -s Device 1024-blocks Used Avail Capacity Type /dev/da0s1b 122880 65148 57668 53% Interleaved 2. At the time of writing I run much more stuff on an AMD Athlon with 512 MB of memory. It has lots of swap space, but what I see is: $ pstat -s Device 1024-blocks Used Avail Capacity Type /dev/ad0s1b 1048576 14644 1033932 1% Interleaved It's not so important that the Athlon is using less swap: it's using less than 3% of its memory in swap, whereas the 486 used 4 times its memory. In a previous edition of this book, I had the example of a Pentium with 96 MB of memory, which used 43 MB of swap. Look at it from a different point of view, and it makes more sense: swap makes up for the lack of real memory, so the 486 was using a total of 80 MB of memory, the Pentium was using 140 MB, and the Athlon is using 526 MB. In other words, there is a tendency to be able to say ``the more main memory you have, the less swap you need.'' If, however, you look at it from the point of view of acceptable performance, you will hear things like ``you need at least one-third of your virtual memory in real memory.'' That makes sense from a performance point of view, assuming all processes are relatively active. And, of course, it's another way of saying ``take twice as much swap as real memory.'' In summary: be generous in allocating swap space. If you have the choice, use more. If you really can't make up your mind, take 512 MB of swap space or 1 MB more than the maximum memory size you are likely to install. For the file systems, the column Mount now shows the mount points, and the Newfs column contains the letters UFS1 for UNIX File System, Version 1, and the letter Y, indicating that you need to create a new file system before you can use it. At this point, you have two choices: decide for yourself what you want, or let the disk label editor do it for you. Let's look at both ways: Creating the file systems _________________________ With these considerations in mind, we'll divide up the disk in the following manner: o 4 GB for the root file system, which includes /usr and /var o 512 MB swap space o The rest of the disk for the /home file system To create a file system, you press c. You get a prompt window asking for the size of the file system, and offering the entire space. Enter the size of the root file system: [Omitting PostScript image images/disk-label-1.ps 4i ] Figure 5-10: Specifying partition size When you press ENTER, you see another prompt asking for the kind of partition. Select A File System: [Omitting PostScript image images/disk-label-2.ps 4i ] Figure 5-11: Selecting partition type When you press ENTER, you see another prompt asking for the mount point for the file system. Enter / for the root file system, after which the display looks like: [Omitting PostScript image images/disk-label-3-a.ps 4i ] Figure 5-12: Allocated root file system It's not immediately obvious at this point that soft updates are not enabled for this file system. Press s to enable them, after which the entry in the Newfs column changes from UFS1 to UFS1+S. See page 191 for reasons why you want to use soft updates. Next, repeat the operation for the swap partition and the /home file system, entering the appropriate values each time. Don't change the value offered for the length of /home: just use all the remaining space. At the end, you have: [Omitting PostScript image images/disk-label-5-a.ps 4i ] Figure 5-13: Completed partition allocation You don't need to enable soft updates for /home; that happens automatically. That's all you need to do. Exit the menu by pressing q.
Description: PGP signature