[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 07:23:16 +1100
User-agent: Mutt/1.2.5i

On Tue, Jan 29, 2002 at 11:51:55AM -0700, Andreas Dilger wrote:
> > Ah right.  For files, it assumes you don't care about geometry.
> > Is there a reason you should care?
> Well, for testing or working with images of disks it is useful.  With DOS
> partitions, you can generally determine the geometry from the partition
> table,

And parted does...

> and for others you probably don't care.

Sun does, but in general no, right :)

>  If there is no partition
> table yet or the geometry cannot be determined by the contents, it should
> be possible to specify it in some way.

Yep, it's a matter of bureaucracy.  I don't like polluting interfaces...
EVMS's parameter interface would be ideal...

Until then, it doesn't seem to be a practical problem.

BTW: what I was suggesting before was having undo literally
undo changes, rather than the plan-commit utopia I described
earlier.  "Literally undo" has the advantage that you don't
have to remember/understand what the incremental changes actually
were... you just have to keep a copy of the partition table,
and a name (probably what the user typed) for the user's
convienience.  The list is a list of partition table states.

The current on-disk state is where the pointer points at.
Earlier entries are old states that we can undo to, and
later entries are "possible futures" that the user expressed
interested in.  (Actually, went to that future, and came back)
Technically, that should be a tree, but that's too complicated,
and probably not useful, anyway.

> > * 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)
> Well, I never understood that much.  If you want to undo something,
> just to redo it, you haven't gained very much.

"oops, I didn't want to undo, and I couldn't be bothered typing
in all the numbers again"

>  What is much more
> useful is to be able to insert or replace an operation earlier in
> the stack, then redo subsequent operations.

Not convinced... if you can't add the operation to the end,
the chances are you're doing major surgery anyway, in which
case you probably want to start over.

OTOH, if you decided that you didn't want to delete
partition X afterall (perhaps Y instead), then that would
work.  Sounds rather difficult though... complicated dag
of dependencies.  (And these are non-trivial to compute...
see below)

Another issue is partition numbers changing.  (Try deleting
a logical partition 5, when you have some others...)
Anyway, users might freak if you insert "rm 5", and see
their old "rm 6" is still in the pipe-line (because
they will believe it refers to the old partition 7,
when it doesn't)

>  This is also harder to
> implement.  Maybe if you undo, then it keeps the tail operations,
> and you then can show, redo, skip/drop, or clear (all) operations
> in the tail?

skip/drop is difficult (see below)

> > * warn if you can't undo?
> Sure.

There's a Special Case TM: when (new) partition table metadata
would overwrite part of old real-data (eg: the partition you
just deleted).  To complicate matters, it's not the
operation you are about to do that is undoable... rather,
you rendered a past operation undoable.

So, imagine deleting and/or inserting operations...
you might be inserting an undoable operation (in which
case, you need to lop-off the head of the list)...
which may only be partially un-undoable (geez, this is
getting complicated - "partially redoable" sounds better?), or
you might be inserting an operation that will conflict
with on operation further down the undo (redo part) list.

Going down this path sounds more complicated than just
implementing ped_file_system_duplicate().  I think the
original undo/redo list thing is fairly simple to implement
(main complication is the metadata thing), so I might entertain
that even for 1.6.x.

Actually, using ped_file_system_duplicate() and
ped_disk_duplicate() together is non-trivial... I began
writing a rant about this... I should finish it.


reply via email to

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