[lvm-team] Soliciting feature requests for development of an LVM library / API

[Kay Sievers]

On Sat, Dec 13, 2008 at 16:23, Alasdair G Kergon <agk at redhat.com> wrote:
> On Sat, Dec 13, 2008 at 03:28:20PM +0100, Kay Sievers wrote:
>> On Sat, Dec 13, 2008 at 02:30, Dave Wysochanski <dwysocha at redhat.com> wrote:
>> > Note that by scanning a single PV we may not be able to answer
>> > definitively what VG it is in or what LVs it may contain.  So provided
>> > we go this route with putting into the udev database all needed
>> > information that today you get from pv/vg/lvdisplay commands, something
>> > else will have to put together individual PV information to get an
>> > accurate picture of the VG / LV info in the system.
>
> When we discussed this with David in Boston, it became clear that the
> udev database as currently implemented was unable to hold the information
> LVM2 needs to store.

Sure, "integrating with udev" does not neccessarily mean depending on
the udev database. It might be a to simple modell, the udev database,
for more complicated span-multiple-devices problems.

What we need is basic information "exported" to the udev database, and
kernel events that trigger a possibly needed update for the stack of
users of udev events. Also some information might be useful in sysfs,
but we should be able to do all that by calling a dm tool at event
time.

> So we started going back to the idea that LVM2 would still needs its
> own database (an extension of /etc/lvm/cache described on a bugzilla
> somewhere IIRC).  Then I was wondering about integrating with upstart
> to handle the rule-based 'triggers'.

You may also want to support systems without udev, and the recover and
rescue systems, where you might not have some dependencies. You will
also need to run properly in initramfs if device-mapper is the root
device, and I'm not sure if thjings like upstart will be there.

> Alternatively we need to find a way to extend the udev database.

Sure, we can do all that if we have a good reason for it.

>> For various reasons we can not afford to open any "unknown" device
>> from these tools or the library,
>
> Indeed - that's what the 'trustcache' setting I added a while back was
> meant for.

Ah, fine. What does this cache do? It's not stored across reboots, right?

> Example walk through:
> /dev/sda appears
> udev notified
> - calls out to md 'is this yours?' - md says 'no'
> - calls out to lvm2 'is this yours?'
>  - lvm2 sees that it is a PV
>      - stores the basic PV label info in a database somewhere
>    lvm2 sees that the PV contains VG metadata
>      - reads the VG metadata - it references 1 other PV UUID
>      - *stores* the vg name, vg uuid, plus PV UUIDs references (1 of which can't yet be resolved to a device) in a database somewhere
>    lvm2 responsds "yes" ie claims the device.  udev stops asking other subsystems
>
> /dev/sdb appears
> udev notified
> - calls out to md 'is this yours?' - md says 'no'
> - calls out to lvm2 'is this yours?'
>  - lvm2 sees that it is a PV
>    - stores the basic PV label info in the database
>  - lvm2 sees that the PV contains VG metadata (nothing to do - already in the database)
>  - lvm2 responsds "yes" ie claims the device.  udev stops asking other subsystems
> A trigger (Upstart?) notices that all the PVs making up a VG are present and that there
> is a rule saying that if this particular VG is seen, all the LVs in it should be activated
> - vgchange -ay  runs on that VG
> 1 LV appears /dev/vg0/lv0
> udev notificed
> - calls out to md 'is this yours?' - md says 'no'
> - calls out to lvm2 'is this yours?' lvm2 says 'no'
> - calls out to mount 'is this yours?'
>  - mount sees there's a (legacy) fstab entry for it
>    - there's a filesystem on it so it mounts it as per rule
>
> Exactly what 'owns' the database, rule engine and triggers makes little
> difference to me - but this is the sort of event-driven functionality I'm
> expecting to see when this project is complete.
> The bit I'm told the udev database can't handle is storing the VG information
> with indexes independent of the PVs.

As said, I'm not so sure about using the udev database to manage
dm/lvm information, it might be just too simple.

But what we really miss is proper integration with udev, which means
that the dm/lvm tools do not create device nodes, export the needed
information, and that the whole stack using udev events gets proper
updates if something changes.

Thanks,
Kay