On Fri, 20 Dec 2002, Daniel Carosone wrote:

> 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.

Please, let's not. If we have an LVM, it will not participate in the
diskpart stuff. Logical volumes aren't partitions, after all. :-)

Yes, they are things you build file systems on top of, but they aren't
really 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.

The marking file system type stuff we will need to support, in the same
way as we do for partitions. But I think we should do it in a manner that
doesn't involve a struct diskpart; if we want to twiddle the type for a
partition, let's just twiddle it. :-)

> 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.

Right, if we have an LVM (which diskpart isn't), we won't need
disklabeling inside of it.

> 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.

Maybe, maybe not. We don't know what the, "NetBSD LVM," will do. If it's
built on top of components in native partition maps (like how RAIDframe
and ccd work now), then there'd be one partition in that disk's diskpart,
of the appropriate type.

However the LVM might just grab the whole disk and not have a "partition"
table on it.

We can decide that bit later.

Take care,

Bill