Re: [d-i] partkit vs autopartkit
Raphael Hertzog wrote:
> Anyway there are several tasks (actually my autoparkit do them all
> (without asking anything though)) :
> - resizing partitions (autopartkit does only resize FAT)
> - creating partitions in the free space (that may have be liberated by
> the previous resize)
> (autoparkit create a fixed number of partitions and calculate the
> size automatically)
> - choosing the mount point and mounting them on /target/mountpoint
> - writing /target/etc/fstab
>
> We need to find a framework to have those steps integrate each other.
That very closly parallells my thoughts. Here's what I wrote up
brainstorming about it last night. One thing that is missing from the
below is that we really want to be able to store info about the choices
made in the debconf db, so that it can be fed into a later automated
install. Which is really quite tricky. Anyway:
------------------------------------------------------------------------------
Disk partitioning and set up is one of the more complex parts of any linux
installer. It involves several other things:
1. Identifying available media, and deciding which to use.
2. Identifying existing partitions, and deciding what to do with
them (delete them, keep them unchanged, resize them).
3. Deciding how many partitions of what sizes and layouts and types
to make.
4. Creating (deleting, resizing) partitions.
5. Deciding where to mount all the partitions.
6. Formatting and initializing filesystems (and swap space).
7. Mounting partitions in /target (and swapon swap partitions)
8. Writing fstab.
Existing tools:
Fdisk and its cousins do steps 2 through 4, and if we want to let power
users use such things, the rest of the system will have to be able to
take the result and continue on. It's probably best to call such
programs before everything else, if they're called at all, and then step
2 just takes whatever they set up as its initial conditions.
Autopartkit does all of these steps itself. That's a valid approach, but it
doesn't scale too well if we want to be able to have:
- Plug in modules for new and exciting filesystem types (reiserfs,
ext3, xfs, raid, etc)
- Various ways to make the decisions that need to be made (user
input, automatically, or some combination).
So we probably want to split the steps up. Where to place the divisions?
Some natural divisions are:
- Everything before step 5 is quite architecture-dependant, while
it and everything following is pretty much the same no matter what
architecture, I think.
- Step 6 can involve a wide array of tools and techniques depending
on filesystem type, and so it would make sense to make it be in
its own step, and acomplished by modules.
- Steps 1 through 3 all involve a lot of decisions, which need to
be made somehow, whether by prompting the user or guesswork. So
does step 5. The rest of the steps mostly only interact with the
user if something goes wrong (though step 6 might need to ask
various questions to tune filesystem parameters).
- Steps 2 and 3 are tightly bound, and if one program does both, it
will probably be able to interact with the user better, since a
single UI can be used, the user may want to jump back and forth,
etc.
- Step 5 could benefit from being bound to 2 and 3 as well. On the
other hand, existing tools (eg: fdisk) do not so bind it.
One way it could be split up would be:
b. Identify media, decide how to partition it, and where to mount
the partitions, and make the partitions. (stages 1-5)
c. Filesystem setup modules. (stage 6)
d. Filesystem mounting on /target, and fstab generation. (stages 7-8)
With this split, c. needs to know what filesystems to make of what types.
This information is not going to be in the partition table. It would have
to be passed from b. to c. somehow. Likewise, d. needs to know what
partitons mount where and what type they are, and again info needs to be
passed from b.
Here's another split:
b. Identify media, decide how to partition it, and where to mount
the partitions, make the partitions, and write a fstab (stage
1-5, and half of 8)
c. Filesystem setup modules. (stage 6)
d. Filesystem mounting on /target. (stage 7)
e. Copy in fstab. (rest of 8)
Here the data is passed in a well-known format: the fstab. Steps c. and d.
should be able to figure out most everything they need to know based on the
fstab, except c. will need to be told which partitions to format, and which
to leave alone.
Yet another split:
a. Identify media.
b. For each media, decide how to partition it, and where to mount
the partitions. Write a fstab.
c. Make the partitions.
d. Filesystem setup modules.
e. Filesystem mounting on /target.
f. Copy in fstab.
This requires that b. pass on to c. data about what partitions to make
where, and that a. tell b. what media there are. It has the advantage
that this b. is quite a bit simpler than previous b's, and we'r maybe only
need to implement media detection and partition creation once per
arctitecture, while there could be several modules each implementing b. in
a different way.
On the other hand, the actual media detection, and the actual partitioning
could just be roken out into libraries, and then b.'s could just use those
libraries, thus avoiding code duplication as well, without the need to pass
so much data around between stages.
I'm still trying to figure out exactly where the steps should be split up.
I guess the only thing I'm sure of is that the filesystem setup step is a
separate step from everything else, and is done by drop-in modules.
--
see shy jo
Reply to: