Date: Thu, 2 Nov 2000 08:32:35 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Marius Bendiksen <mbendiks@eunet.no> Cc: Randell Jesup <rjesup@wgate.com>, arch@FreeBSD.ORG Subject: Re: Like to commit my diskprep Message-ID: <200011021632.eA2GWZ138286@earth.backplane.com> References: <Pine.BSF.4.05.10011021602500.10193-100000@login-1.eunet.no>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:Not to bring out the paint early, but I have a suggestion, should the
:concept of hog partitions be introduced (regardless of whether you stick
:them in disklabel, diskpart, or yadisklabel3): make it possible to define
:multiple variable-sized partitions, with percentile ratio to use from the
:hog-space, ie.
:
:/ 64m
:/var 128m
:/usr 50%
:/home 50%
:
:That would yield more flexibility, at a (hopefully) low additional cost in
:code.
:
:Marius
:
With the size of hard disks today I'm not sure there would be much
need, since generally you will want to specify fixed size partitions
for all but the last one. For me:
/ 128M (so I can have a bunch of debug kernels)
swap 2G
/var 128M (bigger if this is a mail machine)
/var/tmp 128M
/usr 2G
/data1 (remainder)
(/home placed in /, /usr, or /data1 depending)
e.g. there wouldn't be a whole lot of need for a 10G /usr. Once hard
drives got big enough I just left it at 2G.
One thing I am finding myself doing a lot these days is increasing the
block size for things like /data1 - that will often have fewer larger
files. FreeBSD4 reserves 16K of VM per struct buf no matter what, so
increasing the block size from 8K to 16K is a breeze. Larger block
sizes will put more pressure on the buffer cache and may still have
heavy-load deadlock situations , but should also generally work.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011021632.eA2GWZ138286>