Re: [Evms] Userspace model and terminology

[Kevin M Corry]

Here is my understanding of some of your questions. Correct me if I'm wrong
on any of these, Ben.

> > Sector - Standard meaning - lowest level of addressability.  Assumed to
be
> > on a physical device.
>
> Is this going to be a fixed constant?  512 bytes?

This won't necessarily be fixed, but rather will be device and device
driver
dependent. Obviously for a great majority of devices, this will be 512
bytes.

> > Logical Disk - The ordered set of contiguous sectors which
> > comprise/represent a device.
>
> in Parted: PedDevice.  (BTW: need it be a "physical" device?
> Could it be a partition / logical volume, for example?)
>
> > Disk Segment - An ordered set of contiguous sectors residing on a
Logical
> > Disk.
>
> in Parted: PedGeometry
>
> can we just call it a segment?  It's really nice to have
> short names!

I like short names as well. :) Actually, once we decide on a good set of
terminology for the engine, I would imagine many of these names will be
condensed as we become more comforatable with them.

> > Storage Container - A set of one or more Disk Segments.
>
> s/set/ordered set/?  Does it provide a linear address space?
>
> Why not call it a "segment set"?
>
> Also, must the Disk Segments be on the same logical disk?

I believe a Storage Container is supposed to be akin to a volume group. I
don't think the Segments need be on the same Logical Disk. I suppose you
could consider the Container to have a linear address space (internally, at
least). However, you would not be constrained to using the storage space on
the Segments according to that linear mapping. For instance, striping as
done in the Linux LVM (or even regular volumes with PE's that have been
moved
around) would break such a linear mapping within the Container.

I think Storage Containers came about to accommadate volume-group-based
LVMs,
such as the Linux LVM and the AIX LVM. A module emulating one of these LVMs
would take in Disks and/or Segments, and internally create one or more
Storage
Containers. From these Containers, it would create LVM-compatible volumes,
which would be treated by the next level as Storage Regions.

> > Storage Region - An ordered set of logically contiguous sectors
residing in
> > a Storage Container.
>
> Do you mean, "An ordered set of Disk Segments?".  Actually, how
> is this different from a Disk Segment, other than the "Disks"
> are "Disk Segments" other than "Logical Disks"?
>
> Perhaps you should call this an "ordered segment set"?
>
> Also, what's the motivation for saying that it's "in a Storage
> Container"?

Again, the motivation is to accomadate modules that are emulating existing
LVMs. Keep in mind, of course, that if you aren't using an LVM emulation
module, your Storage Regions will be equivalent to your Disk Segments. As
far as the engine is concerned, the Segments will pass through some
"generic"
Container, which won't make any modifications. This is done just to keep
the
layering consistent. (In the kernel, however, this Container would not
actually exist, and the Segments would be passed directly to the feature
level during discovery.)

> > Storage Object - A logically contiguous address space created from one
or
> > more Storage Regions or Storage Objects through the use of one or more
EVMS
> > Features.
>
> It should be abstract / undefined how it is "created".  It should
> have an identical interface to a Logical Disk, IHMO.
>
> > Volume - A mountable storage object.
>
> See previous comment.
>
> > Device Manager - responsible for producing Logical Disks.
>
> I think "Disk Manager" is better, if you are going to use
> "Logical Disks".
>
> Andrew Clausen

I'll let Ben (or any of the engine guys) comment on the Objects and
Volumes.
I guess I'm more of a Container guy. :^)

Kevin