Subject: Re: Graphical Sysinst in 2.0
To: None <current-users@NetBSD.org>
From: Chapman Flack <flack@cerias.purdue.edu>
List: current-users
Date: 09/07/2004 22:45:52
> > The other calculation I would like to see present in the calculation
> > of disk sizes is that if you want a 128MB filesystem, it figures in
> > metadata overhead such that you get a 128MB filesystem.
>
> 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 the
An *integrated* install tool might not have to ask me - or it would be able
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 tool,
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.
What I thing would be very cool: throw together a script that runs over
all the install sets on NetBSD.org for current and past releases, collecting
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 release
adds a tuple of data. The data built into sysinst for a given release could
just be the extracted-size for each current set plus the current estimate for
growth rate, and the overhead models for the available filesystems and their
tuning parameters, and you could say to the installer something like "I want this
partition to contain sets X, Y, and Z, and N Mb of my own data that I project
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 straightforward
but tedious enough that people's eyes glaze over, which is just the kind of
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?
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.
-Chap