[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Surprise-dev] GNU Parted and Partition Surprise

From: Jan Kratochvil
Subject: Re: [Surprise-dev] GNU Parted and Partition Surprise
Date: Mon, 23 Jul 2001 01:38:01 +0200
User-agent: Mutt/1.3.19i

On Mon, Jul 23, 2001 at 08:41:11AM +1000, Andrew Clausen wrote:
> On Sun, Jul 22, 2001 at 05:36:11PM +0200, Jan Kratochvil wrote:
> > Parted: Client requests one-by-one the specific actions it wants.
> > 
> > Surprise: Client requests 'how it should look in the final'. All the 
> > necessary
> >           (minimal) changes are found and performed by the library.
> The question for me is: "what interface?"!

I don't think that it makes sense to think about it: 'final state layour' is
more comfortable for the user, more useful for change optimizations. It is
harder to implement it to the libsurprise/libparted but it is simply better.

Do you have any positive reasons why to specify the actions from client

> > And I still think that you are not able to change EVERY parameter of the
> > filesystem. Is it really possible to set everything of ext2 filesystem?:
> > 
> > block_size       - Block size
> > inodes_count     - Inodes count
> > bytes_per_inode  - Bytes per inode
> > blocks_per_group - Blocks per group
> No, the ext2 resizer is a traditional one.  Grow and shrink are
> 2 different operations (that have a single interface), and they are
> basically incremental FS operations.

Don't try to defence too hardly, I'm not attacking your code. :-)
I was just advocating our filesystem module LOCs - that they are really not

> These are trivial!  tune2fs can do these:
> > reserved_percent - Reserved space in percents
OK, OK, I just took "src/libsurprise/fs/ext2/params.m4". And it looked better.

> Also, there's another issue:  what if you want to do changes in steps?
> eg: you want to swap the on-disk order of 2 partitions.  The plan was
> to have checkpoints of file system state, that you could
> ped_file_system_commit() to.
> i.e.
>       fs = ped_file_system_open (some_partition->geom);
>       ped_file_system_resize (fs, some_smaller_size);
>       check1 = ped_file_system_push_checkpoint (fs);
>       ped_file_system_resize (fs, target_loc);
>       ped_file_system_commit (check1);
>       // other stuff on other fs's in here, perhaps
>       ped_file_system_commit (fs->head_checkpoint);
> Just, it became a reference nightmare - particularly for partition
> table stuff.  (For example: how do you undelete a partition?
> how do you preserve and/or invalidate references?  Do you use
> pointers, indirection, handles...?)
> Things become more Interesting when you allow copying of file
> systems...

I don't know what exactly are you requesting here. Some checkpoint interface to
the client application or it should be visible even to the user? Both (where
the second requires the first anyway) are currently implemented in Surprise
Gnome client.

Such 'checkpoints' are purely client-side issue in our approach as you can only
save your 'Final states', libsurprise doesn't need to know about any
'checkpoints' as it is only called with the final request for the disk commit
phase. libsurprise offers some utility functions for example to duplicate/free
'Final states' but it doesn't master such operations in any way.

When you run Surprise Gnome client, there is Edit->Undo History window where
all the performed actions are listed. You can retreat to any previous state.
When you commit the changes physically to the disk, you can still review the
previous states but you can no longer make changes to them (as such changes
would arise from no-longer-existing physical representation).

It is implemented as use-counting transactional object system (to be glib
objects based, not yet) with weak and strong references. Each object (such as
partition, disk or free space) is referenced from all current undo-states. When
you for example delete partition, the partition object in fact remains existing
(as hidden) as it is still referenced from the state 'before-partition-delete'.
Only in the case you Undo to some state older-than-'before-partition-delete'
and you will do some action, all the further trailing undo-states get
destroyed (general Undo principle, for example as in VIM) and the partition
object will be in this case destroyed.

Management of objects (disks/partitions/free):  src/client/gnome/phys.[ch]
Partition-objects matching phase, general mng.: src/client/gnome/parter.[ch]
Undo states list, Undo History window:          src/client/gnome/undo.[ch]

Undo system has to be implemented if you are in progress of doing some action
which couldn't be finished for some error. Also there can be sub-Undo-actions
performed, during sub-action failure you have to retreat to the last finished
top-level state. Undo History window should be GtkTree in fact, currently it is
only GtkCList (with tree items linearized to the list, hierarchy is used only
on several code points anyway).

Undo system can be also found in Jack's Curses client although I can proudly
say that the Gnome client's one is probably more sophisticated :-). Gnome has
to always find a minimal set of GUI changes between the current and the
requested Undo states to not to flash with GUI too much.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]