On Thu, Dec 19, 2002 at 04:46:16PM -0800, Bill Studenmund wrote:
> I was trying to say that as best I can tell, LVMs won't make use of
> wedges. i.e. LVMs won't be just another partitoin type; they will be an
> entirely different beast.

For now, lets just assume LVM's do private and magical things inside
its components to make mirrored/striped/raid5/etc chunks into a
sequential logical block device, and that we don't want to speculate
how just yet.

What are the things we do want to specify, so we can allow the
magic to happen later; indeed allow multiple forms of such magic?

The LVM needs to find components, and present the resulting LVs.

Having done the magic, it might present those block devices to the
kernel and userland as "partitions" within one of Bill's diskpart's.
To borrow and mix other LVM's terminology, there might be a volume
group presented as a diskpart, with logical volumes presented as
partitions.

This allows the rest of the system, and userland tools, to see a
consistent interface and use the lv's like now, including such
regular useful labelling things as marking filesystem type, read-only
flags, sizes, etc.  Seems helpful. 

We address this today for raid(4), ccd(4), cgd(4), vnd(4), and
possibly others by treating the LV as a whole new synthetic PV -
and putting another disklabel inside.  Perhaps that's better, but
if the LVM is really doing its job nicely we shouldn't need further
partitioning inside.

It also allows parts of the potential LVM configuration to be done
by userland tools outside the kernel, without inventing new interfaces
for non-LVM-specific tasks.

The earlier question is how the LVM finds its components, which is
a little like Greg's PV manager.  

I see this happening just like Bill proposes to find "plain" diskpart
partitions:  when a disk is configured, various label formats are
read from it and components "discovered".  Just like discovering
other NetBSD partitions, this process is likely to vary from platform
and system.

Some of those components will be partitions, in any scheme,
marked as "NetBSD LVM". This is needed so that the disk sectors
are understood by other OS's (and non-LVM NetBSD) to be none of
their business.  Some might avoid the further nesting, especially
where no sharing is required.

--
Dan.