bug-parted
[Top][All Lists]
Advanced

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

More stuff on operation queues


From: Andrew Clausen
Subject: More stuff on operation queues
Date: Wed, 21 Feb 2001 04:00:29 -0300

Hi all,

I've been thinking lots more about this stuff :-)

For file systems:

* when resizing, you need to have the old and new
file system.  Unless there is no file system.
I probably just confused the hell out of you all,
so I'll try again: resizing has two meanings... issuing
the request with ped_file_system_resize() and actually
doing it with ped_file_system_commit().
        Inside ped_file_system_resize(), you need to
know the old file system, so you can verify that it's
doable, ask questions (FAT16 or FAT32...?), ...
        Inside ped_file_system_commit(), you need
to know the old file system, to know what needs to
be copied, etc.

* the old file system can be stored as a checkpoint.
This seems the Right Thing to do.

* you don't have an old file system, when creating
from scratch.  Therefore, this behaviour seems to
suggest itself:

        (1) creating/opening a file system creates
        a PedFileSystem with no checkpoints.  If
        opening a file system, mark it as "on-disk".

        (2) resizing a file system.  If the file is
        system marked as "on-disk", then push a
        checkpoint (and the checkpoint will remain
        marked as "on-disk"), and remove the "on-disk"
        mark from the file system.
                Then, if there is a previous checkpoint,
        use, that to determine if you can do the operation,
        etc., and update the metadata in the file system
        (in memory).
                If there is no previous checkpoint,
        then just apply the changes.

        (3) copying a file system.  First, the prototype:

        PedFileSystem*
        ped_file_system_copy (PedFileSystem* fs)

        So, this is sort of like fork().
        I think we should keep the checkpoints common
        (i.e. same pointers, etc.) across both ends of
        the fork.  Commits after the fork should (somehow)
        only be allowed if the point-of-the-fork is
        on-disk.  Also, we need some mechanism for saying
        the copy operation should go first (maybe this
        should be the caller's responisibility)

BTW, we should allow doing funky things like:

        ped_file_system_commit (fs->prev_checkpoint)

also, ped_file_system_commit() should destroy previous
checkpoints (Exception: for copy), and should mark
the file system as "on-disk".

This is still a bit incoherrant, but I think this is
all working out :-)  Once I get some code working...

Andrew Clausen



reply via email to

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