Date: Sat, 08 Dec 2001 13:15:08 -0800 From: Jordan Hubbard <jkh@winston.freebsd.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Garance A Drosihn <drosih@rpi.edu>, "Louis A. Mamakos" <louie@TransSys.COM>, Sheldon Hearn <sheldonh@starjuice.net>, Kirk McKusick <mckusick@beastie.mckusick.com>, freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) Message-ID: <49294.1007846108@winston.freebsd.org> In-Reply-To: Message from Matthew Dillon <dillon@apollo.backplane.com> of "Fri, 07 Dec 2001 19:49:32 PST." <200112080349.fB83nWU00292@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Ok, I've finally gone and done it... cleaned up the sysinstall
> 'Auto' option.
OK, I have the following concerns with this:
First I don't think that the concept of dynamic sizing and adding a
bunch of extra default filesystems should be intermingled at all. I
think they should be introduced one at a time and more gradually, both
in order to obey the POLA since a lot of people (most?) use this
feature and also because, for technical reasons, I think they're
actually layered features and should be more carefully implemented if
anyone's going to go down this road at all.
To put it another way, I like the idea of more intelligent dynamic
sizing for the existing set of default filesystems and would support
that without reservation since the current set of default filesystems
(/, /usr, /var) was rather deliberately chosen to represent the lowest
common denominator of what a user might want *regardless* of the
mission profile of the machine (OK, /var is currently too small for
some missions, but that's orthogonal since we're not talking about the
sizes, we're talking about the default set).
I've also avoided addressing this feature for as long as I have
because I knew that going to the next logical step would involve a lot
more than just beefing up certain defaults and adding a few more
filesystems to the mix - that would have been easy. The minute you
take that easy out you also start making the configuration less
generic and more mission specific, even if the mission is defined by
your own biases as to what "generic" means. If you're going to go
down that road at all then you might just as well admit from the start
that what you need are multiple canned mission profiles and not just a
single set of defaults which feel best to you but will probably just
annoy a lot of other people.
From a technical perspective, I think it could be handled by a little
table structure that looked something like this:
struct fs_item {
char *name; /* mountpoint */
int min_size; /* minimum size of filesystem in MB */
int def_size; /* default size */
int size_inc; /* MB size increment to bump up or down */
};
struct disk_profile {
char *name; /* "mail", "news", "desktop", etc.. */
char *long_desc; /* long description for menu */
struct fs_item members[0]; /* list of filesystems */
};
Then you could have:
struct disk_profile profiles[] = {
"mail",
"A small-to-midsize mail server",
{ { "/tmp", 50, 100, 1 },
{ "/var", 50, 100, 1 },
{ "/var/spool", 200, 1000, 10 } },
"news",
"A USENET news server",
...
};
And allow the user to select a base profile from a menu or toggle
through the available set with a keystroke if you want to make it
available from the label editor. The lower-level code should then
just take one of these structures as an input and shuffle things
around until it can find the closest fit given the policy information
it has to work with.
I know this substantially expands the scope of the changes you're
contemplating and I also know how easy it is to say (and irritating it
is to hear) "that's not enough, you need to do a bunch more work
before I'll be satisfied", but I really do feel that this is one of
those features where you either have to keep things really simple and
as policy-free as possible, as they more or less are now, or you need
to go to a substantially higher level and apply more of an "expert
system" type of approach if you want to make more decisions on behalf
of the user. I don't see any middle positions with real value.
- Jordan
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?49294.1007846108>