On Sat, Dec 13, 2008 at 16:23, Alasdair G Kergon <a...@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 <dwyso...@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 _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
