On Sat, Dec 13, 2008 at 03:28:20PM +0100, Kay Sievers wrote:
> On Sat, Dec 13, 2008 at 02:30, Dave Wysochanski <[email protected]> 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
-- 
[email protected]
_______________________________________________
devkit-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/devkit-devel

Reply via email to