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

[Andrew Clausen]

On Mon, Jul 23, 2001 at 01:38:01AM +0200, Jan Kratochvil wrote:
> 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
> step-by-step?

Perhaps I didn't explain very well.

I think it should be possible to move between arbitary states in one
go (which is what Partition Surprise does)

However, imagine you have 2 partitions:

        AAAAaaBBBBbb

(A,a represent partition A,  B,b represent partition B, and
lower case represents free space on the partition)

And you want to swap the order.  You need to do something like:

        AAAAaaBBBBbb
        AAAA  BBBBbb
        AAAABBBB
            BBBBAAAA
        BBBBbb  AAAA
        BBBBbbAAAAaa

Make sense?
So, you can't just commit to the final state immediately...
if you commit B to it's final state, it will clobber A.

> > > 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'm just saying that only the FAT resizer has the Interesting stuff.
(The "No" was an answer to "is it possible?")

> I was just advocating our filesystem module LOCs - that they are really not
> superfluous.

OK.

> > 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.
> :-)

Of course, it's still good that you have a nice interface ;)

> 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.

Ah, ok.  Makes sense.

> 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).

Right.

> 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.

Right.  That stuff is somewhat complicated, which is why I'm waiting for
glib...  glib doesn't have any docs for gobject though :/

Anyway, it's really cool to see these problems solved... I'll go away
and meditate on this for a while, hehe ;)

Andrew