[Top][All Lists]

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

Re: unit sizes and parted

From: Andrew Clausen
Subject: Re: unit sizes and parted
Date: Wed, 30 Jan 2002 04:30:46 +1100
User-agent: Mutt/1.2.5i

On Tue, Jan 29, 2002 at 09:33:36AM -0700, Andreas Dilger wrote:
> > This means parted couldn't figure out the geometry on your
> > disk... it should have told you.
> Well, it didn't mention it, but yes, it was a file and not a disk device.
> I figured that out after I sent my email, and hence the "need to be able
> to specify a geometry" in my second email.

Ah right.  For files, it assumes you don't care about geometry.
Is there a reason you should care?

> Well, for complete recoverability, that would be needed.

The idea is: you want to avoid writing *anything* until the user
types "commit", and everything magically happens.

Before this point, everything is "predicted".  Constraints have
to be computed for both partition tables and file systems, in
advance.  This is already possible for partition tables in
1.5.x, but not yet for file systems (it shouldn't be too hard)

Anyway, you need operation queues for undo (while editting
"what needs to be done").  It doesn't help with recoverability.
(You'd actually have to store the queue/set somewhere)

>  However, even
> basic recoverability would help.  For example, before I realized that
> there was no "undo" function I _almost_ wiped the partition table on
> my primary machine because I wanted to see what GPT partitions looked
> like (it is perfectly safe to play around with fdisk until you hit "w").
> Luckily, I decided I should use a test file instead.
> Having a backup copy of either the binary or logical structure of an
> existing partition table would be a huge benefit at very little expense.
> This might be similar to what LILO does when it first writes the MBR,
> or the "sfdisk -O <file>" option.

The only expense is making a nice UI.  All the code in libparted
is ready (hint: ped_disk_duplicate()).

But, making a "backup" of a partition table seems like a bad
idea if the operation also affects on-disk data.

Also, what about multiple levels of undo?

Hmmm, here's an idea:
* you can only undo to the last operation that doesn't modify
file systrems
* undo always undoes the last operation... hit undo multiple
times to go back to the beginning
* redo?  (doable... just have 'where-you-are-at'  be a pointer
in a list, and when you add an operation, delete the tail of
the list, and replace it with the operation)
* warn if you can't undo?



reply via email to

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