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

[Andrew Clausen]

On Sun, Jul 22, 2001 at 01:54:17PM +0200, Jan Kratochvil wrote:
> BTW have you really read "docs/sgml/{user,tech}.sgml" ?

Will do.

> Yes, verything is "doable" in Parted but you need to write special 'module' 
> for
> each feature. IMO the whole filesystem rebuild takes it more simple and
> straightforward (and slower).
> 
> For example filesystem conversions in Parted need N^2 (N=supported filesystem
> types) modules while Surprise needs only 2*N modules (2='import' and 'export'
> part of the filesystem module).

Understood.  But, I proposed a much less efficient way that parted can do
it in with N modules.

> It has one big performance hit: You really need to move the data between A and
> B. Surprise only rebuilds metadata so it should be much faster.

Right.   So it will probably be a constant factor slower.

> But I don't think that conversion speeds are too much important so yes, you 
> can
> do it by your proposed way - why not? When I was talking with my friend admin,
> I was saying that Surprise is currently pretty slow as it doesn't yet have 
> much
> acceleration functions. He answered that it he does't matter how it is slow as
> he really doesn't mangle his disks every day. The need for speed is maybe a
> professional deformation of partitioning software hackers. :-)

Hehe ;)

> > Parted's approach is also simpler / easier to maintain.  (Another reason
> > I didn't try doing a generalize resize / whatever)
> 
> You have: shrink, grow, reblocksize, convert-to-X, convert-to-Y, ...

Wrong.  There is one function: ped_file_system_resize().  The fat_resize()
function, for example, can shrink, grow, change block size, convert between
fat16 and fat32, etc.

As I said before, I've thought about a lot of the issues that you have,
and some things in the design a similar.  (The idea of representing old vs
new file system, etc.)

> Everything as separate functionality - it is much more code I think than
> 'import' and 'export' approach. A much more code to debug. While you will be
> adding more supported filesystems (and their conversions), the code base will
> grow to unmaintainable sizes.

Well, the "slow conversion algorithm" eliminates all coupling between
FS code.  If we want to go faster, then your system is better.

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

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

> > Anyway: it would have been wise for you to talk to me when you discovered
> > Parted.  I'm sure we've learned lots from our experiences, and have lots of
> > tricks to tell each other ;)
> 
> There is one _problem_: This was a university team project and unfortunately 
> it
> isn't wised to just extend foreign project (Parted) - such 'extension' would
> then be hard to advocate as OUR OWN PROJECT.

How pathetic!  (/me curses univeristy bureaucracy)

> So when it is now written it would be nice to look at the code and designs
> which are better in both of the projects and merge it somehow (we planned to
> merge Parted to our more-general-approach codebase before our project got into
> its current stagnation).

Right.

> > Also, the partition handling code in parted should be shared, IMHO.
> > It would be fairly easy to add a
> > 
> > ped_disk_convert (PedDisk* disk, PedDiskType* new_type)
> > 
> > (this is planned ;)   (Note: PedDisk represents a partition table)
> 
> /* You have to set the partition table type in a loop through all the
>  * partitions of the disk as separate partitions of the same disk can be in
>  * different partition tables:
>  * PC partition table can have BSD partition table as its sub-space.
>  * Such shared partition table we identify by UP_ID_PTBL_PCBSD.
>  */
> 
> disk=final->fi_exp_disks+disk_no;
> for (part_no=0; part_no<disk->di_count; part_no++) {
>       disk->di_up[part_no]->up_entry_type = UP_ID_PTBL_MAC; /* for example */
>       /* We want the partition enty fields to be recalculated: */
>       disk->di_up[part_no]->up_entryvalid = 0;
> }
> commit_disks(final,NULL,0,ERR_PASS);
> 
> This is not planned, it is working.

I could implement it in about 50 LOC with current libparted - i.e. no API
changes required.  (So, why don't I just do it now?!  Well, it's after
midnight...)  The complexity comes into adjusting the partition locations
to match the new alignment constraints, and resizing appropriately.

> > There's lots of duplication... (apart from anything else, us thinking
> > about the same ideas twice)
> 
> It was partially a duplication but it was needed due to the damned school.

Yeah :(

> > Also, one question: is it safe to interrupt a "generic conversion" ?
> > (eg: power failure)
> 
>  And it is designed for
>   pertient future support of journalling.

Sounds good.

Andrew