On Tue, 4 Jul 2000, Christian Limpach wrote:

> This sounds good, althouth I would add another device-level called lvm,
> either at pseudo or at the config root.  lvm0 would be configured at boot
> time and then I could ioctl lvm to allocate a new vg, then initialize this
> vg and ioctl it to allocate new lv's.  This way pseudo doesn't need to know
> about vg's and how to allocate them.

I think Jason Thorpe is working on something like this now. He's doing it
more from not having to statically config network interfaces, but it's the
same thing.

> But this also raises some more questions:
> - why don't ccd, vnd and raidframe use this system?  They are very similar
> to lvm when it comes to resources used and resources provided.  Would it
> make sense to convert them to use the same system?  If not, why use a
> different system for lvm?

Yes, it would make sense to convert them to do the same kind of thing. :-)

> - shouldn't a vg attach to the partitions it uses for storage?  let me
> explain this wrt to ccd, since people are more familiar with ccd's:
> a ccd using /dev/wd1e, /dev/wd2e and /dev/wd3e would attach to the wd1e,
> wd2e and wd3e devices.  This raises the following question:

I'd say the vg should be attaching to partitions a la ccd.

> - shouldn't a partition be a device?  wd1a attaches to wd1, wd1b attaches to
> wd1 and so on.

What would that gain? There is very little per-partition information (open
info, partition size & offset, and fs info). Making them devices would
complate all of the subsystems which deal with them. Also, these devices
would come and go as the disk partitioning layout changes and partitions
are added & deleted. I'm not sure how that would help.

The main thing we need AFAIC see is that other devices like ccd, raid, or
lvm drivers can grab partitions and whole disks. I think we have that.

Take care,

Bill