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

[Alasdair G Kergon]

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.

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

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

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

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.

Alasdair
-- 
agk at redhat.com