On Tue, 26 Jun 2012, Norman Golisz wrote:
Hi Darrel,
On Tue Jun 26 2012 14:58, Darrel wrote:
We have less limitation on partitioning these days, so /usr/obj
was obvious- actually had that one before. I chose /usr/src and
/usr/local as well, and expect that this was unimportant unless
moving into NFS or some special circumstance.
no, this isn't necessarily true. Think of FFS' block alignment feature,
using different mount options, file system optimisations, etc.
I have looked at some of the things that folks are doing with /var
on ZFS. I understand that ZFS is not within the scope of this
list; however, does anyone have some neat ideas about partitions
under /var?
Particularly, I am interested in /var/crash, /var/tmp, and /tmp.
I would not personally have any use for a crashdump, unless it
would be to pass it along to someone who could make use of it. I
basically want the partitions to be set up logically.
Typically etc, usr, tmp, var, home, and / have been enough. /usr/obj
is an excellent addition and so does someone have recommendations
of further refining my scheme for OpenBSD51?
I used /altroot for the first time on OpenBSD50, but had to modify
fstab like this:
#bb128e900f20094a.d /altroot ffs xx 0 0
/dev/wd0d /altroot ffs xx 0 0
I guess that /var/crash should be crafted to memory and that
Hmm. No. Be aware that the kernel dumps the entire physical memory to
swap. When rebooting, savecore(8) copies the dump to /var/crash.
Therefore, it needs to be at least as big as available system RAM + a
few bits more. You see why mfs is not suited for this.
/var/tmp as well as /tmp can actually be very small?
Yes, they can. But it depends on your setup. See, /tmp can become scarce
when your web browser stores its temporary data there, e.g. video data.
And, one further hint, you should place /var/tmp on non-volatile
storage, as it is supposed to hold temporary data between reboots,
whereas /tmp can safely be an mfs.
My imperfect configuration looks like this:
~ $ df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/sd2a 509M 64.0M 420M 13% /
/dev/sd2p 44.8G 29.1G 13.5G 68% /home
/dev/sd2d 1001M 793M 158M 83% /usr
/dev/sd2e 502M 196M 281M 41% /usr/X11R6
/dev/sd2f 6.9G 2.7G 3.8G 42% /usr/local
/dev/sd2i 2.0G 1.1G 812M 58% /usr/obj
/dev/sd2k 4.9G 384M 4.3G 8% /usr/ports
/dev/sd2l 3.9G 87.4M 3.7G 2% /usr/ports/pobj
/dev/sd2g 2.9G 890M 1.9G 31% /usr/src
/dev/sd2h 2.0G 552M 1.3G 29% /usr/xenocara
/dev/sd2j 2.0G 495M 1.4G 26% /usr/xobj
/dev/sd2m 123M 17.4M 99.8M 15% /var
/dev/sd2o 246M 5.1M 229M 2% /var/log
/dev/sd2n 123M 96.0K 117M 0% /var/tmp
mfs:4517 495M 109K 470M 0% /tmp
Thank you, Norman.
I plan to borrow some of this. I have been slow this time- most machines
are getting a fresh reinstall.
My 5.0 boxes have 3g on /usr/obj and 2g on /usr/src.
I tend to get old computers from folks that upgrade and actually have a
DNS Server running on an Intel built for windows95. :)
And for the sake of comparison, I have a FreeBSD machine with ZFS
filesystem mostly backup up video and it looks like this:
(70) @ 23:39:38> zfs list
NAME USED AVAIL REFER MOUNTPOINT
bigD 32.8G 37.6G 672M /
bigD/swap 4.13G 41.7G 57.1M -
bigD/tmp 44K 37.6G 44K /tmp
bigD/usr 27.8G 37.6G 312M /usr
bigD/usr/distfiles 31K 37.6G 31K /usr/distfiles
bigD/usr/home 23.9G 37.6G 23.9G /usr/home
bigD/usr/local 421M 37.6G 421M /usr/local
bigD/usr/obj 2.44G 37.6G 2.44G /usr/obj
bigD/usr/packages 31K 37.6G 31K /usr/packages
bigD/usr/ports 435M 37.6G 435M /usr/ports
bigD/usr/src 351M 37.6G 351M /usr/src
bigD/var 156M 37.6G 1.28M /var
bigD/var/backups 1.04M 37.6G 1.04M /var/backups
bigD/var/crash 31.5K 37.6G 31.5K /var/crash
bigD/var/db 153M 37.6G 152M /var/db
bigD/var/db/pkg 1.30M 37.6G 1.30M /var/db/pkg
bigD/var/empty 31K 37.6G 31K /var/empty
bigD/var/mail 31K 37.6G 31K /var/mail
bigD/var/run 55K 37.6G 55K /var/run
bigD/var/tmp 32K 37.6G 32K /var/tmp
Darrel
