[Top][All Lists]

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

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

From: Andrew Clausen
Subject: Re: [Surprise-dev] GNU Parted and Partition Surprise
Date: Mon, 23 Jul 2001 09:54:45 +1000
User-agent: Mutt/1.2.5i

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:


(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:

        AAAA  BBBBbb
        BBBBbb  AAAA

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.


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


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


reply via email to

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