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

[Jan Kratochvil]

On Mon, Jul 23, 2001 at 12:03:22AM +1000, Andrew Clausen wrote:
> On Sun, Jul 22, 2001 at 01:54:17PM +0200, Jan Kratochvil wrote:
...
> > > 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.

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.

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


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

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
reserved_percent - Reserved space in percents
max_mount_count  - Maximal mount count
check_interval   - fsck interval
error_handling   - Error handling
volume_name      - Volume name

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.

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

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.

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

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.

I wrote that code example primarily for the reason you wrote that you are
"planning it", it was perfect ball pass. :-)


                                                        Lace