Date: Sun, 4 Sep 2005 15:28:23 -0400 From: "C. Michailidis" <dinom@balstonresearch.com> To: freebsd-stable@freebsd.org Subject: Sysinstall FS sizing defaults [was: Sysinstall automatic filesystem size generation.] Message-ID: <200509041528.24038.dinom@balstonresearch.com> In-Reply-To: <200508290609.42070.dinom@balstonresearch.com> References: <000d01c5ac73$0e4fbb50$6b2a15ac@SMILEY> <200508290609.42070.dinom@balstonresearch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 29 August 2005 06:09 am, we left the discussion here:
>=20
> <...> Isn't it safe to make some of the default sizes a=20
> wee bit larger? That is, a 256mb /tmp and /var doesn't seem=20
> "appropriate" if you have one of these massive modern disk=20
> drives. For christ's sake, I'd gladly give up a GB or two of=20
> /usr so I could build openoffice without needing to consider=20
> that I may need an extra few megabytes in /var at the time of=20
> the system install.
>=20
<...>
>=20
> Wouldn't it be smart to remove the hardcoded default sizes=20
> altogether and dynamically generate them according to a=20
> reasonable function?
> > Probably, but a template for something like this isn't simple unless
> > it's created as part of a general profile-based installer that would
> > inform sysinstall of the machine's purpose in life. =A0For example, a
>=20
Since the original thread got hijacked by the soft-update/write-cache/reise=
rfs/journalling crowd I've renamed the thread (LOL).
Now, maybe it's just a waste of my time but... I started creating patches f=
or sysinstall to provide rudimentary functionality of this nature. My init=
ial goal is to provide a handful of options to the user after they've chose=
n to automatically create their partitions (using the 'a' key during disk l=
abelling). I'm pretty sure that other disk partitioners do this and I can'=
t think of a reason why we (as FreeBSD users) shouldn't have it available t=
oo.
I've come up with the following profiles based on past discussion in this m=
ailing list thread:
Desktop Modern multimedia or development workstation. Normal
sized root partition. Extra space will be allocated to
the tmp and var partitions and the remainder of the slice
will be allocated to the usr partition.
Server Normal sized root and tmp partitions. A larger var
partition will be created for server and log files and
the remainder of the slice will be allocated to the usr
partition.
Monolith The entire slice will be allocated to the root partition.
This labeling strategy insures that you won't run out of
space on any single sub-partition. However, by splitting
your data over multiple filesystems (i.e. choosing another
option) it is more likely that the system will still come
up after a catastrophic failure making it easier for you
to restore from backup as necessary.
Generic This will label the slice with traditional default
partitions. You may choose this option if you are unsure
of the ultimate use of the system.
I cannot proceed with the implementation of the 'behind-the-scenes' code un=
til finalizing this set of options. Thus, I am petitioning the list for fe=
edback to this capricious endeavor. Ultimately, I envision each additional=
profile/labeling strategy to be a slight variation on the "generic" (i.e. =
current) implementation of auto-labeling; except of course for drastically =
different strategies like "monolith". My thought is when a larger /var or =
/tmp is called for by a profile, instead of using the hardcoded defaults - =
the value used could be the larger of either 2 times the existing default o=
r ~2 percent of the slice in question. In more concrete terms...
xxx_default_size =3D (XXX_DEFAULT_SIZE*2 > space_free(label_chunk_info[here=
].c)*2/100) ? XXX_DEFAULT_SIZE*2 : space_free(label_chunk_info[here].c)*2/1=
00
=2E..or something to that effect would be added in a few places around line=
1535 of sysinstall's "label.c". I don't think any of the profiles should =
change the default swap partition size determination. Although arguments f=
or changing the default swap partition size may be interesting, I do not be=
lieve any of the profiles should do this (laziness you know). ;-)
If you have any suggestions, comments, or constructive criticisms I'd love =
to hear them. I believe the utility of these patches will (largely) be det=
ermined by the kind of feedback I receive. So... please, if you can think =
of a profile you would desperately like to see or you notice some absurditi=
es in the profiles I've come up with, do not hesitate to reply.
Otherwise, I'll finish up the changes and offer the unified diffs for inclu=
sion in your system.
Thanks,
Dino
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200509041528.24038.dinom>