On Sat, 1 Jul 2000, Christian Limpach wrote:

> I looked and this made me realise, that I still had some catching-up to do
> on some basic designs used in the kernel.  I hope to get a better
> understanding of how things work.

:-) It can take a while. :-)

> > > the whole lvm system, except that I'm somewhat unclear on these points:
> > > - is the number of items in one pool limited or is there a performance
> > > advantage to use different pools for each vg or each lv?
> 
> anybody?

Items in a pool have to all be the same size, so I think you want a pool
per vg, and a pool per lv. But Jason would know better.

> I have a static struct disklabel dk_label;
> and I do this:
>   lvmfakelabel (&dk_label, minor);
>   ((struct partinfo *)data)->disklab = &dk_label;
>   ((struct partinfo *)data)->part =
>       &dk_label.d_partitions[0];
> 
> This works as long as whoever calls DIOCGPART is not storing the returned
> pointers for later reference.  This will not work too well on an SMP
> machine.  In conclusion, a shared struct disk for the whole LVM system is
> not a good idea.

Yeah, one per lv would be fine.

> > It would be nice, but no one's implimented it yet. :-(
> 
> I wouldn't mind implementing it if such a change is welcome.

I think the ability to do things that way would be apperciated, as long as
you don't break the static method. :-) Among other things, some times lots
of pseudo-devices (like tunnel interfaces) are created, and we'd rather
not see all the output.

The trick is you need a way to be able to come along and say, now add one
more. For the vg's, that's easy. You have a control channel which says,
here's a new vg. For other users of the pseudo-device framework, like ppp
or slip, you don't. The only way they get told how many there are is at
init. :-)

> I'm also trying to make the way lv's and vg's find each other more how
> similar things are done in other places in the kernel.
> 
> I would need to know what exactly is a softc structure?  disk(9) suggests
> that it should have a struct device and struct disk while the softc used for
> the vnd and ccd devices doesn't have a struct device.  If a softc can be any
> structure, then I would only have to do some renaming since I use already
> structures for vg's and lv's.  If a softc for a disk device should have a
> struct disk, as suggested by disk(9) then I should probably add one to
> either the vg or the lv structure since a shared struct disk for the whole
> lvm system has the problems mentioned earlier.

I think part of the problem is that you've been loking at pseudo devices,
which have more relaxed rules than real devices. "Real" device softc's
start with a struct device, and also know who their parent is, which is
also a struct device. All the way up to the root device. "Real" device
softc's are generated by the autoconfig system when each device is found.

Given that, the best way to do what we've been describing would be to add
something like a device "pseudo" which lives off of the config root. Then
have vg* attach at pseudo?, and your lv* attach at vg? .

Your vg-configuring code would then attach a vg onto the "pseudo" device.
Well, tell code in the "pseudo" driver that you found one of these here
devices (a "vg"), and it sould attach it. I guess look at how pcmcia &
such find & detach things.

> So it's either one struct disk for each volume group or one struct disk for
> each logical volume.  The first option limits the number of logical volumes
> to MAXMAXPARTITIONS since all the logical volumes would be listed as
> partitions in this struct disk's disklabel.  The second option has no such
> limit but wastes more memory.

I think option two is fine.

> If I use option two, the structures would look something like this:
> struct lv_softc {
>   struct disk sc_dkdev;
>   [.. whatever has been in struct lv until now ...]
> };
> struct vg_softc {
>   [.. whatever has been in struct vg until now ...]
> };
> Is this about right?  Or is there something mandatory for a softc which
> would make vg_softc a real softc as opposed to just a structure and thus the
> whole change just a cosmetic change?

See config discussion above. :-)

> I would then disk_attach/detach whenever the kernel is made aware of a
> new/removed logical volume.
> 
> Thanks for you replies so far, they have been helpful!

You're welcome. :-)

Take care,

Bill