3 Commits

Author	SHA1	Message	Date
Peter Rajnoha	8d1d83504d	udev: fix pvscan --cache -aay to trigger on relevant events ... This patch fixes the way the special devices are handled (special in this context means that they're not usable after the usual ADD event like other generic devices): - DM and MD devices are pvscanned only when they are just set up. This is the first CHANGE event that makes the device usable (the DM_UDEV_PRIMARY_SOURCE_FLAG is set for DM and the md/array_state sysfs attribute is present for MD). Whether the device is activated is remembered via DM_ACTIVATED (for DM) and LVM_MD_PV_ACTIVATED (for MD) udev environment variable. This is then used to decide whether we should fire the pvscan on ADD event to support coldplugging. For any (artificial) ADD event generated during coldplug, the device must be already set up properly to fire the pvscan on it. - Similar for loop devices. For loop devices, only CHANGE events are relevant (so there's a CHANGE after the loop device is set up as well as detached). Whether the loop has just been activated is detected via loop/backing_file sysfs attribute presence. The activation state is remembered via LVM_LOOP_PV_ACTIVATED udev environment variable. - Do not pvscan multipath device components (underlying paths). - Do not pvscan RAID device components. - Also, set LVM_SCANNED="1" udev environment variable for debug purposes (it's visible in the lvmdump -u that takes the current udev database). This variable is set once the pvscan is triggered. The table below summarises when the pvscan is triggered (marked with X, X* means fire only if the special dev is properly set up): | real ADD | real CHANGE | artificial ADD | artificial CHANGE | remove ============================================================================= DM | | X | X* | | X MD | | X | X* | | loop | | X | X* | | other | X | | X | | X	2013-09-10 16:27:58 +02:00
Peter Rajnoha	4d3b5724e0	udev: inform lvmetad about lost PV label ... In stacked environment where we have a PV layered on top of a snapshot LV and then removing the LV, lvmetad still keeps information about the PV: [0] raw/~ $ pvcreate /dev/sda Physical volume "/dev/sda" successfully created [0] raw/~ $ vgcreate vg /dev/sda Volume group "vg" successfully created [0] raw/~ $ lvcreate -L32m vg Logical volume "lvol0" created [0] raw/~ $ lvcreate -L32m -s vg/lvol0 Logical volume "lvol1" created [0] raw/~ $ pvcreate /dev/vg/lvol1 Physical volume "/dev/vg/lvol1" successfully created [0] raw/~ $ lvremove -ff vg/lvol1 Logical volume "lvol1" successfully removed [0] raw/~ $ pvs No device found for PV BdNlu2-7bHV-XcIp-mFFC-PPuR-ef6K-yffdzO. PV VG Fmt Attr PSize PFree /dev/sda vg lvm2 a-- 124.00m 92.00m [0] raw/~ $ pvscan --cache --major 253 --minor 3 Device 253:3 not found. Cleared from lvmetad cache. This is because of the reactivation that is done just before snapshot removal as part of the process (vg/lvol1 from the example above). This causes a CHANGE event to be generated, but any scan done on the LV does not see the original data anymore (in this case the stacked PV label on top) and consequently the ID_FS_TYPE="LVM2_member" (provided by blkid scan) is not stored in udev db anymore for the LV. Consequently, the pvscan --cache is not run anymore as the dev is not identified as LVM PV by the "LVM2_member" id - lvmetad loses this info and still keeps records about the PV. We can run into a very similar problem with erasing the PV label directly: [0] raw/~ $ lvcreate -L32m vg Logical volume "lvol0" created [0] raw/~ $ pvcreate /dev/vg/lvol0 Physical volume "/dev/vg/lvol0" successfully created [0] raw/~ $ dd if=/dev/zero of=/dev/vg/lvol0 bs=1M dd: error writing '/dev/vg/lvol0': No space left on device 33+0 records in 32+0 records out 33554432 bytes (34 MB) copied, 0.380921 s, 88.1 MB/s [0] raw/~ $ pvs PV VG Fmt Attr PSize PFree /dev/sda vg lvm2 a-- 124.00m 92.00m /dev/vg/lvol0 lvm2 a-- 32.00m 32.00m [0] raw/~ $ pvscan --cache --major 253 --minor 2 No PV label found on /dev/vg/lvol0. This patch adds detection of this change from ID_FS_LABEL="LVM2_member" to ID_FS_LABEL="<whatever_else>" and hence informing the lvmetad about PV being gone.	2013-08-26 15:40:16 +02:00
Peter Rajnoha	6dd70f472a	Call built-in blkid conditionaly (udev version >= 176), call standard blkid ... with full path otherwise.	2012-02-20 19:38:40 +00:00