Subject: Re: Graphical Sysinst in 2.0
To: Chapman Flack <>
From: Bill Studenmund <>
List: current-users
Date: 09/08/2004 15:08:47
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 07, 2004 at 10:45:52PM -0500, Chapman Flack wrote:
> > Depends on how good you want it to be. If you're happy with 128 MB after
> > the 5% reserved for root bit, then that should be easy. An integrated
> > install tool (does both the partitioning and formatting) could ask you =
> An *integrated* install tool might not have to ask me - or it would be ab=
> to present me with the reasonable range of choices based on what it knows
> about the filesystems.  After all, it is the dedicated NetBSD install too=
> and I'm not.
> That was one of the things I most wished for in my first encounter with
> sysinst - I wondered why it wasn't able to give me breakdowns of the space
> requirements for the different installation sets, ask me which sets I
> wanted in which partitions, offer me reasonable defaults, and give me
> detailed information that helped me design the partitions.  I actually
> wound up, for some of my size estimates, going and downloading the OpenBSD
> Guide, which has a nicely detailed section on partitioning, and assuming
> the sizes might not be too different.

The problem is that we don't exactly know how big the sets are. We have=20
default install sizes (which may need updating), but that's it.

> What I thing would be very cool: throw together a script that runs over
> all the install sets on for current and past releases, collect=
> the (extracted) size and datestamp for each.  It could be done just once
> to make a little historical database available on the web site, with
> regression results estimating the growth rate for each set.  Each new rel=
> adds a tuple of data. The data built into sysinst for a given release cou=
> just be the extracted-size for each current set plus the current estimate=
> growth rate, and the overhead models for the available filesystems and th=
> tuning parameters, and you could say to the installer something like "I w=
ant this
> partition to contain sets X, Y, and Z, and N Mb of my own data that I pro=
> to grow r percent/yr, and I want this partition to be reasonably sized for
> the next m months."
> That's an example of the kind of calculation that's perfectly straightfor=
> but tedious enough that people's eyes glaze over, which is just the kind =
> thing to go in a tool that does more than simply automate the same steps a
> person could manually do just as quickly.
> Wild idea?

I think the idea of knowing how big the sets are is a good one. I think=20
the idea of embedding the size into the application is not so good. I=20
don't think it will scale at all well.

I think what would work better is to change how sysinst sets things up=20
(the order) and locate the sets sooner in the process. Include a file with=
the sets that contains all the sizes, a manifest if you will. This file=20
could also include what sets actually are there (x sets, what multitude of=
kernels are present), sizes, and other info we want. Then sysinst can make=
better recomendations. Also, if you're doing an update, it can tell you if=
it thinks there won't be room.

> btw, for people who care about what partitions can be made rdonly and the
> like, the division of existing install sets does not mirror the pure-/var
> division, so it might be good to keep both sizes for each set, and have
> the tool assist with a setup where /var is separate  ... as another poster
> pointed out, with current disk sizes there's less reason to separate / and
> /usr, but still rather good reason to separate {/ /usr} and /var.

I think having /usr, /var, and all-other-/ would be good sizes.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)