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

[Andrew Clausen]

On Sun, Jul 22, 2001 at 05:36:11PM +0200, Jan Kratochvil wrote:
> I've looked now at it and in fact it will also rebuild FAT metadata structures
> from the scratch, so this isn't too much different from Surprise.
> 
> The whole differences can be summarized as:
> 
> Parted: Client requests one-by-one the specific actions it wants.

This is merely an interface issue.  The FAT resizer itself could very
easily be adapted to a different interface (and I've been experimenting
with this, BTW)

The question for me is: "what interface?"!

> Surprise: Client requests 'how it should look in the final'. All the necessary
>           (minimal) changes are found and performed by the library.

This is how the FAT resizer is structured... but the ext2 resizer is
a "traditional" one.

> > > What do you see complicated on 'import' or 'export' filesystem parts?
> > 
> > Well, the fact that your resizers are double the LOCs of ours (and your
> > coding style is denser than mine).  It doesn't look excessive, though.
> > That said, I reckon it can be simpler :P  But I need to study it more...
> 
> LOC advocacy: For example Robert's FAT file system is able to store all ext2
> information to special files during conversion for loss-less conversion back 
> to
> ext2 (when dumb user converts it by a mistake).

Interesting.  (This was another reason I felt uneasy about such a thing
... trying to match up the difference is semantics in the FSs)

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

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.

> block_size       - Block size
> inodes_count     - Inodes count
> bytes_per_inode  - Bytes per inode
> blocks_per_group - Blocks per group

These are trivial!  tune2fs can do these:

> reserved_percent - Reserved space in percents
> max_mount_count  - Maximal mount count
> check_interval   - fsck interval
> error_handling   - Error handling
> volume_name      - Volume name

Parted doesn't have a general interface for changing "FS values",
although I intend to use GObject properties for that, if/when we
switch to using glib's GObject system.

> In fact I didn't found any way to set filesystem parameters in your "parted"
> command-line client. :-?  I haven't checked any of the availale third-party
> frontends, though.

Right.  That's the (only) problem.

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

> > > Note:
> > > These parts don't solve anything about overlapping filesystems, this 
> > > problem is
> > > left for General Converter.
> > 
> > I don't understand... what do you mean?
> 
> When you convert ext2->fat, fat FATs want to be in the same place as (for
> example) the original inode table of ext2. This is a problem as you cannot
> rewrite inode table of ext2 while you haven't yet imported all the data of it
> (from ext2). So you need to write fat FATs to some other temporary place and
> then move them to their right position when ext2 has been completely imported.

Right.

> So I wanted to say that this problem is not visible to the filesystem module
> layer so the filesystem modules import and export their data as if the
> partition would be completely their. Such "temporary places" are solved
> exclusively by our General Converter.

This is "obviously necessary", IMHO.  i.e. "I thought of this too".
(Which isn't that important, except that it's a pity we weren't talking
earlier!)

> Hmm, yes, the alignment requirements can be different, it wasn't solved in my
> example. Surprise-design-flaw explanation: It is already being solved in at
> least Surprise Gnome client, I'm not sure about Surprise Curses client. This 
> is
> still one of the design problems, some code is now being duplicated across the
> clients as there wasn't much time left before deadline to keep it unified. 
> Some
> functionality from the clients should be moved down to the common libsurprise.

OK.

Andrew