Sysinstall FS sizing defaults [was: Sysinstall automatic filesystem size generation.]

[C. Michailidis]

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
            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 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.

Thanks,
Dino