Thanks a lot to all that replied either in private email (Francisco), or in the misc mailing list (Joachim, Robert, Will, Stuart, Peter, Damian, Marc and Matthias).
I will try to reply to all in the thread right now. As I am not a member of this mailing list I have not received a copy of the emails. I will try to set up nmh to automatically classify email from two or three mailing lists to receive these lists as soon as possible. Sorry for the delay, but the first message was stalled because it included certain words that make it seem as spam (a word that I will not repeat here, because I do not want this message to be stalled again!) I agree with Francisco about the use of swap (wd0b) for both memory filesystems (/tmp and /var/run). Indeed, it is the way it is used in fstab(5), but only on a single mfs. Both Francisco, Damian and Joachim have observed that /var can grow when using databases or the system is a large mail or printer server. I should have observed it as I sometimes work for the Department of Geological Sciences, and they send huge files to the plotters. It is a very good point. Joachim is right when he writes that /home does not need to be too large. Currently it can grow up to, we say, 1 GB (e.g., when making an ISO image to be dumped to a CD-ROM) but large /home filesystems are a waste of space. Indeed, /usr/X11R6 is part of /usr. Even if some packages install files on it (e.g., OpenMotif), X11R6 does not grow a lot and can be considered static. I guess that I made it a separate filesystem because I do not see X.Org as a part of OpenBSD (another reason is that /usr/openwin was a separate filesystem on Solaris, and I am accustomed to this layout). A too large /usr/ports is something that should be avoided for me, as I really use binary packages. I just install /usr/ports because sometimes I needed to build packages from source (it happened only a few times.) Certainly a 24 GB /usr/ports is something I will probably avoid. On this matter, I feel that Damian is NOT doing something improperly when /usr/ports grows. It would be much better having these object files in /usr/obj or, at least, not lying around in /usr/ports. Building ports from source makes /usr/ports a real mess in only some days. I am sure, there are good technical reasons for not making the object and binary files in a separate directory: patches to source code tarballs would become unmanageable if third party applications need to be changed to support this feature. The advice on CCD is an excellent one (thanks Joachim!). I would suggest leaving some unused space on the disk drives too. It is not the same as Veritas Volume Manager, but can certainly help when a filesytem runs out of space. Certainly using CCD or RAIDframe is much better. I agree with most people in this thread. The setup I proposed is too complex. I like it and works fine for me, but it is certainly a nightmare when a new application changes the space requirements (and a database is a good example). Indeed, I do not run databases right now... but I should do it. Databases are not only useful as support tools for spam filters and intrusion detection systems, but excellent tools for our daily work. I will play with a database system as soon as I have some time. Again, thanks to all for the excellent advices on this matter. Cheers, Igor. --Boundary_(ID_b6vZWPMJJsiMXjf61E2EHw)--
