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.

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

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

  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

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

           [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.

Attachment: pgpSmBYj1iZi9.pgp
Description: PGP signature

Reply via email to