On Fri, Nov 10, 2006 at 05:55:27PM +0100, Igor Sobrado wrote:
> Hello.
> 
> I have some questions related with the layout of the filesystems
> on OpenBSD and hope someone will be able to help me.  I must start
> saying that I never had problems with this setup, but I certainly
> would appreciate some advice on it.  To make things clear, I will
> try to outline the output of /etc/fstab, disklabel and df on a table:
> 
>    -----------------------------------------
>       Mounted on  Type  Size    bsize  fsize
>    -  ----------  ----  ------  -----  -----
>    a  /           ffs    64 MB  16384  2048
>    b  swap        swap  512 MB  N/A    N/A
>    c              <all the disk>
>    d  /altroot    ffs    64 MB  16384  2048
>    e  /var        ffs    25 MB  16384  2048
>    f  /usr        ffs   768 MB  16384  2048
>    g  /var/log    ffs    16 MB  16384  2048
>    h  /var/mail   ffs   128 MB  16384  2048
>       /var/run    mfs     4 MB
>    i  /var/tmp    ffs    24 MB  16384  2048
>    j  /var/www    ffs    32 MB  16384  2048
>    k  /usr/X11R6  ffs   256 MB  16384  2048
>    l  /usr/local  ffs  2048 MB  16384  2048
>    m  /usr/obj    ffs   896 MB  16384  2048
>    n  /usr/ports  ffs   512 MB  4096   512
>    o  /usr/src    ffs  1024 MB  8192   1024
>    p  /home       ffs     + MB  16384  2048
>       /tmp        mfs    64 MB
> 
> It is, approximately, the layout of all my systems.  Not all computers
> have the same filesystems structure.  For example, servers (currently
> a Soekris net4801 and a Dell PowerEdge 350) do not run X, nor have
> /usr/X11R6 on it.  I do not extract the contents of XF4.tar.gz on any
> of my systems (workstations or servers) either.
> 
> There are no filesystems with more than 50% space used and, to avoid
> running out of inodes, /usr/ports and /usr/src have no default block
> and fragment sizes either.
> 
> My questions are:
> 
>   1. /var/run and /tmp are memory filesystems right now.  (/tmp does
>      not need to survive to reboots and the contents of /var/run
>      are better going away when the machines are restarted.)  Both
>      have entries on /etc/fstab with the SAME BLOCK SPECIAL DEVICE
>      (/dev/wd0b).  Is it a good practice?

No idea; I suppose it doesn't really matter.

I have /tmp on disk. I can see why you'd want to do it that way, but
according to http://www.openbsd.org/faq/faq4.html#Partitioning, you'd
want it to be larger when compiling software.

>   2. Are the sizes of the filesystems right ones?  I am thinking on
> 
>        - "/var" (on the installation booklet provided with the OS
>        it is recommended a size of 200 MB for this filesystem,
>        I *never* found a /var filesystem larger than 10-20 MB).
>        Can it really be so large?

I suppose, but it does need something to actually get it that large.
Large (mail|print) spools and log files come to mind.

>        - "/usr/obj" (what is the maximum size required for making
>        a full operating system rebuild?)  I will certainly not
>        do a full rebuild, only apply some patches, but it is
>        better to know.  Today, storage space is cheap and we
>        can afford a 900 MB filesystem... my current estimation
>        comes from some "make world" on NetBSD... it would be
>        nice to know the amount of space that is required.
>        Can we use the default block/fragment sizes on it?

/usr/obj is 936M on my -current i386 box (and includes the result of
'make release'). Better up that estimate a little.

>        - "/usr/ports" (is 512 MB enough for it?)  I usually stay
>        at binary packages, but sometimes I need to build software
>        from source and would like to know the recommended space
>        for this filesystem.

/usr/ports is only 160M on my box. This should not include any build
stuff.

Depending on what you want to build, 512MB can be plenty or far too
little (OpenOffice comes to mind...)

>      I know that some filesystems (e.g., /var/mail and /var/www) are
>      too small for most uses, but the size of these filesystems is
>      very easy to know once we know how a computer will be used.
>      On these machines I do not need a large /var/mail (only one
>      of these machines receive standard email -not system reports-
>      and it is stored in /home as soon as I run the inc(1) command
>      in nmh.)  Others (e.g., /usr, /usr/X11R6, /, /altroot -that is
>      a dump of the root filesystem automatically done-) do not
>      grow at all.
>
>   3. Any though about the filesystem layout?  I know that it is
>      certainly complex, but worked nicely for me in the last years.
>      All these filesystems (except /var/tmp) are recommended in
>      the documentation and, as I said, I do not remember any of
>      these filesystem growing up to 60% in either space or inodes
>      usage in the last years... but I never did a full rebuild
>      of the operating system nor installed large packages from
>      source code (mwm is soo nice, and it comes in the official
>      CD-ROMs!)

It's more complex than it needs to be; and I find that having a gob of
unused disk space is really handy (don't mount it, though - it will take
forever to fsck).

Since you've already discovered altroot, note that it can be trivially
extended to altusr and such. Especially for /usr, this can be rather
handy if you do something stupid. (Only recommended if you have some
disk space lying around doing nothing; / is quite useful in recovery,
but /usr is just nice.)

My systems typically do not have a /var/tmp, although I could see why
you'd want one; /usr/X11R6 is part of /usr (there is no point in
separating them, is there?), /usr/local is also part of /usr (although
there might be a point in separating those), and on the build systems,
/usr/obj, /usr/src, /usr/ports and friends all share a single disk
(symlinks are neat!).

If you mean that /home takes up the rest of the disk, don't do that.
Unless you actually use the machine as a workstation, 64 MB should do
it. 256 is nice, but anything more is just wasteful. (On most servers,
/home only holds some login information and a couple of SSH files; it
doesn't require a lot of space).

(Other systems either have no source code, or access it via an NFS
mount; this is not quick, but works well for looking up a couple of
functions.)

                Joachim

Reply via email to