Re: new PedDisk interface

[Andrew Clausen]

Damien Genet wrote:
> > I've been thinking a lot about a new PedDisk interface.
> > Motivation for changes:
> > * automatic partitioning, allowing things like simulated annealing
> 
> sory, i don't understand what a simualted annealing is :(

It's an idea from thermo-dynamics.  If you cool crystals slowly,
they come out stronger / more uniform.

If you "randomly" do Parted commands (in memory), then you might
strike upon a good partitioning scheme.  If you come up with
a good probability distribution for the randomness of parted
commands, then that should help.  If you make it less-and-less
random (cool more slowly), then that should help also.

Make sense?

I have no idea how feasible this is going to be (it all depends
on how fast we can make the libparted code, and how well
we can come up with a good probability distribution, given the
partitioning "goals")
 
> hmm, but you will have to push a chekpoint after each (user) operation,
> that's what user are waiting for an undo stuff (, no ?)

Yes.  But each "user" operation might be many operations on the
disk label.  Eg, I should implement gpart functionality... it's
trivial.

> > Yes, it's UGLY.  I hate it.  Better ideas?
> 
> can't we only duplicate changed objects, ie : only partition, fs....
> but so you can't use chekpoints i think, or you must predict what will
> be changed before pushing a chekpoint,
> hmm, this can be done if ped_disk_push_checkpoint() is called in the
> beginning of each "acting" function like (ped_partition_destroy()...
> ped_file_system_resize()...).
> but, then i'm not sure this is still the idea of chekpoints.

I was only talking about PedDisk's / PedPartition's here.  Of course,
we should do the same thing for PedFileSystem's, so we should discuss
that now, too ;-)

Anyway, what you say looks right, but I think it's easier to implement
"duplicate everything".

> > Perhaps a better way to refer to partitions (and everything else), than
> > pointers?  Perhaps some identifier code is assigned for PedPartitions,
> > PedFileSystems, etc.  Then, for checkpoints, we just need to duplicate
> > everything.  Only the PedDisk* needs to have it's address preserved -
> > but it's contents don't change, anyway.
> >
> > Comments?
> 
> sory, i don't see much how identifiers can help, can you explain
> more ?

Well, if we duplicate everything, then pointers aren't preserved.
Eg: if you have a:

        PedPartition*   my_root_partition;

and you do a checkpoint, and you pop the checkpoint, then
my_root_partition won't get preserved.

Instead, we could assign a number to all libparted objects.  We should
provide some mechanism for mapping ID's to pointers.  (Vice versa
is easy, because we have part->id, or whatever).

> > Side note: the checkpoint stuff can be implemented after the rest.
> > I intend to do "the rest" RSN.  i.e. fork off 1.5.x RSN.
> >
> > If some people have no idea what I'm talking about, then please
> > prod for a deeper explaination.  My mind isn't thinking properly
> > today!
> >
> > Andrew Clausen
> 
> so i resume, for the moment we had 3 different ideas:
> * inversible operations

This needs that ID thing also, because it doesn't preserve pointers.
(Well, it may be possible to make it preserve them, but it seems
too complicated to me, because I think it would have to be
implemented for each disk label, and applying the inverse operation
doesn't always work.  For example: we can't grow the block size
of FAT, but we can shrink.  We could "force" the reverse, but it
seems scary...)

> * duplicate only changed objects

yeah, we could duplicate everything that we change.  However, how
we store these duplicated objects seems complicated.  We can store
duplicated disks easily enough.  Eg:

        struct _PedDisk {
                PedDisk*        next_check_point;
                /* blah blah blah */
        };

pop_check_point would kill the PedDisk, and return next_check_point,
I guess.

> and the main problems are:
> * fs stuff must be predict

Yeah applying this stuff to file systems is interesting.  The good
thing about file systems is we don't expose any pointers from
inside it, like we do with PedDisk's.

Predicting constraints for FAT is trivial, I think.

(1) fat_open() shouldn't read in FATs or anything like that.  We
should make it really fast.  (This is already a problem, because
programs like MI open all file systems, to get all constraints,
to show them to the user.  So, MI takes an age to start, and
we should fix it)

(2) we should always have a "current" and "original" PedFileSystem
(sounding like checkpoints already!)  Actually, we already have
this in FatOpContext (these ideas were going through my mind
that long ago!)  Then, on the "current", we just write changes to
the appropriate variables (like cluster_size, etc.).  Then,
fat_commit() changes "original" to "current".

The fat_resize() function is actually a lot more generic than
just resizing.  It could be renamed (with a bit of rearranging
with the FatOpContext stuff) to fat_commit().

For now, we can do the same thing with ext2 - just the only
thing that can change is the minimum size, and perhaps some
stuff for copy (the ext2 code doesn't support this, but
ped_file_system_copy() fakes it, by doing a "dd" type thing,
followed by a resize).  Of course, the vapourware resize-the-start
changes things...

> * interraction between  current code and operation list

The above suggestions still require operation lists, because
not all operations can be committed at once.  Eg: swapping
the on-disk order of two partitions.

So, I envisage Parted becoming:

(1) checkpoint()
(2) prompt for command, and apply (in memory) - i.e. don't
commit.  If successful, checkpoint().  Also, push the command
onto a stack.
(3) if user wants more commands, goto (2)
(4) pop all checkpoints (we now know that all commands
are valid)
(5) apply all commands in order

To do undo: just pop a checkpoint, and pop a command off the
stack.

Andrew Clausen