[prev in list] [next in list] [prev in thread] [next in thread] 

List:       evms-devel
Subject:    [Evms-devel] Re: [Evms-announce] Please avoid CVS for a few days...
From:       Andrew Clausen <clausen () gnu ! org>
Date:       2001-09-09 0:22:02
[Download RAW message or body]

On Tue, Aug 28, 2001 at 05:49:32PM -0500, Steve Pratt wrote:
> As a result of input from many of you, we have made some somewhat
> significant changes to the EVMS Engine.   The main reason for these changes
> is to support stacking of region managers as well as the stacking of
> partition managers (Yes Andrew we were listening! ).  In the process we
> used what we had learned over the past 6 months and hopefully simplified a
> number of items.  See Steve D.'s append for a list of other items
> addressed.

I've had a look at latest CVS.  It's *much* better now :)

Comments:
* what's the motivation for logical_volume_t, as opposed to
storage_object_t?  Everything extra logical_volume_t provides
(serial_number, minor_number and flags... THAT'S ALL!) could
be put into private_data, and accessed by special accessor methods.
(in other words, a logical_volume_t is a special kind of
storage_object_t)  What do we need these things for, anyway?
Couldn't all storage objects conceivably need them?

Of course, there is one big exception: file_system_manager.  So,
here's my radical suggestion:

* notice how plugin_func_s and fsim_func_s look very similar?
The following are shared:

 - auto_select_option
 - can_delete (can delete an FS when unmounted?)
 - can_expand[_by]
 - can_move (return NO for FSs)
 - can_shrink[_by]
 - commit_changes (nice idea for FSs, maybe difficult to implement,
since most FS implementations are incremental rather than
reconstructive.  In practice, I don't think it's too hard)
 - create == format (for FSs)
 - delete == clobber look-alike from parted? (for FSs)
 - direct_plugin_communication
 - discover == is_this_yours
 - expand
 - fsck could be called "check", and would be equally applicable...
 - get_acceptable_objects == get_acceptable_volumes
 - get_plugin_info.  (the other get_*_info functions are merely helper
functions... why are they in the virtual table?)
 - init_options
 - move (why not move FSs?  Parted can...)
 - suspend/resume and snapshot_{start,end} could also be in plugins?
 - shrink

In fact, the only methods that DON'T overlap are:
 - read, write, translate*

there were two big things I wanted you to change:
* make all IO address spaces volumes (done!  COOL!!!)
* make everything either a consumer or producer

RANT
----
At the moment, there are 3 abstractions that
deal with volumes:

* containers
* plugins
* fsims (file system interface modules)

Containers consume 1..n volume, and produce 0..m volumes.
Plugins consume 1 volume, and produce 1 volume.
FSIMS consume 1 volume, and produce 0 volumes.

So, it's no surprise that the only serious differences between the
plugin and fsim vtables are read, write and the 2 translates... these
are operations to do with the produce volume, which an FS obiously
doesn't have.

Notice also, that to produce a volume, you also need to consume one.
(Exception: perhaps the "operating system" or hardware produce without
consuming...)

Therefore: I proposed two abstractions:
* a consumer, that consumes 1..n volumes
* a producer, that is a consumer (and shares the same interface,
consumes 1..n volumes, etc.) and produces 0..m volumes

Containers and plugins are producers, and FSIMS are consumers.

Perhaps, it would be more convienient to have a 1-producer, which
consumes and produces exactly 1 volume (i.e. a plugin).  This makes
it easier to do stacking (when stacking B on A, you attach B's
*only* consumed_volume to A's *only* produced_volume).

Anyway, when I suggested this kind of polymorphism, (where producers
are also consumers, and share an interface), there was confusion about
how to implement this in C.  Should I write a prototype, or something?
Or send a big patch for EVMS itself?  (This might take me a while!)

BTW: I've never actually compiled EVMS, because I need to have an
EVMS kernel, etc.  Does it run out-of-the-box under user-mode-linux?
That is a lot more convienient for me ;)  (Especially as 2.4.x is
rather unstable on my box, running natively)

What's a good way of stacking patches?  UML touches init/main.c,
because it has it's own block device (files from it's parent
Linux)  It doesn't look to hard to merge, apart from small things
like that...

Is it possible to decouple evms-engine and evms-runtime all together?
FWICT, it's just stuff for communicating between
plugins/containers/fsims between the engine and runtime.  It would
be nice if the runtime could speak to other kernels (including old
linux's).  I imagine the freebsd and hurd people would be
interested, for example...

Also, the other big gripe I had was the shrink/grow/move/slide/
get_minimum_size/get_maximum_size/... thing.
I think it's possible to do get_create_constraint(),
get_resize_constraint(), get_copy_constraint() (resize == copy,
except resize has an on-disk overlap, copy does not), and a
resize() method only.  So, this would replace about 10 functions
with 2.

BTW: I thought of a solution to the grow/shrink ordering
problem.  Reminder of the Problem: when shrinking a big stack of
plugins (or whatever - you know what I mean ;), you need to shrink
the FS first, but when growing, you must grow the FS last.

What's really going on here is, to do any resize operation, you
must have both the old and new volumes around.  i.e. the old and
new data must be accessible, during the resize operation.

Therefore, the generalized resize algorithm (i.e. shrink/grow/slide,
but NOT relevant to move/copy...  they don't have this problem) we
want is:

(1) resize the volume size at the bottom of the stack (from the
logical disk end) to MAX(old_size, new_size).  Repeat, working up
the stack (towards the FS).

(2) resize the file system to it's new size

(3) work down the stack (from FS towards logical disk), resizing to
new_size (rather than MAX(old_size, new_size))

BTW: to do resize-the-start, you can generalize "size" to (start, length)
tuples, and define a MAX operation to have start=min(start1, start2)
and end=max(end1, end2).  (length = end - start + 1)

Anyway, feel free to flame!

Andrew

[prev in list] [next in list] [prev in thread] [next in thread]