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
