Sysinstall FS sizing defaults [was: Sysinstall automatic filesystem
dinom at balstonresearch.com
Sun Sep 4 12:25:11 PDT 2005
On Monday 29 August 2005 06:09 am, we left the discussion here:
> <...> Isn't it safe to make some of the default sizes a
> wee bit larger? That is, a 256mb /tmp and /var doesn't seem
> "appropriate" if you have one of these massive modern disk
> drives. For christ's sake, I'd gladly give up a GB or two of
> /usr so I could build openoffice without needing to consider
> that I may need an extra few megabytes in /var at the time of
> the system install.
> Wouldn't it be smart to remove the hardcoded default sizes
> altogether and dynamically generate them according to a
> 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. For example, a
Since the original thread got hijacked by the soft-update/write-cache/reiserfs/journalling crowd I've renamed the thread (LOL).
Now, maybe it's just a waste of my time but... I started creating patches for sysinstall to provide rudimentary functionality of this nature. My initial goal is to provide a handful of options to the user after they've chosen to automatically create their partitions (using the 'a' key during disk labelling). 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 too.
I've come up with the following profiles based on past discussion in this mailing 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
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 until finalizing this set of options. Thus, I am petitioning the list for feedback 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 or ~2 percent of the slice in question. In more concrete terms...
xxx_default_size = (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/100
...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 for changing the default swap partition size may be interesting, I do not believe 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 determined 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 absurdities 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 inclusion in your system.
More information about the freebsd-stable