From owner-freebsd-arch Sat Dec 8 13:15:48 2001 Delivered-To: freebsd-arch@freebsd.org Received: from winston.freebsd.org (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 5F07237B405 for ; Sat, 8 Dec 2001 13:15:43 -0800 (PST) Received: from winston.freebsd.org (jkh@localhost [127.0.0.1]) by winston.freebsd.org (8.11.6/8.11.6) with ESMTP id fB8LF8q49298; Sat, 8 Dec 2001 13:15:08 -0800 (PST) (envelope-from jkh@winston.freebsd.org) To: Matthew Dillon Cc: Garance A Drosihn , "Louis A. Mamakos" , Sheldon Hearn , Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Proposed auto-sizing patch to sysinstall (was Re: Using a larger block size on large filesystems) In-Reply-To: Message from Matthew Dillon of "Fri, 07 Dec 2001 19:49:32 PST." <200112080349.fB83nWU00292@apollo.backplane.com> Date: Sat, 08 Dec 2001 13:15:08 -0800 Message-ID: <49294.1007846108@winston.freebsd.org> From: Jordan Hubbard Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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