--GPJrCs/72TxItFYR
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 =
the
>=20
> An *integrated* install tool might not have to ask me - or it would be ab=
le
> 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=
l,
> and I'm not.
>=20
> 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 NetBSD.org for current and past releases, collect=
ing
> 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=
ease
> adds a tuple of data. The data built into sysinst for a given release cou=
ld
> 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 th=
eir
> 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=
ject
> to grow r percent/yr, and I want this partition to be reasonably sized for
> the next m months."
>=20
> That's an example of the kind of calculation that's perfectly straightfor=
ward
> 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.
>=20
> 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=
=20
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=
=20
kernels are present), sizes, and other info we want. Then sysinst can make=
=20
better recomendations. Also, if you're doing an update, it can tell you if=
=20
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,

Bill

--GPJrCs/72TxItFYR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBP4LvWz+3JHUci9cRAo0kAJ9ivcYM2fV85ZpVTFGdNMmNkAldWwCfRjbB
x2VsJd8X5cYnoZ+utpD6y6o=
=iCDZ
-----END PGP SIGNATURE-----

--GPJrCs/72TxItFYR--