~registry/lvm2/master : changes

~registry/lvm2/master » Changes from revision 7316

From Revision 7309 to 7290

Rev	Summary	Authors	Date
7309	logging: add debug classes logging: add debug classes Add log/debug_classes to lvm.conf to allow debug messages to be classified and filtered at runtime. The dm_errno field is only used by log_error(), so I've redefined it for log_debug() messages to hold the message class. By default, all existing messages appear, but we can add categories that generate high volumes of data, such as logging all traffic to/from lvmetad.	Alasdair G Kergon	11 years ago
7308	lvmetad: fix format1 updates lvmetad: fix format1 updates fmt1 doesn't have a separate commit function: updates take effect immediately vg_write is called, so we must update lvmetad at this point if we're going to go on and ask lvmetad for the VG metadata again before calling the commit function (though that's probably an unsupported and pointless thing to do anyway as the client must already have that data and it cannot have changed because it's locked and with devs suspended we shouldn't be communicating with lvmetad; so when that's fixed properly, this fix here can be reverted). This problem showed up as an internal error when lvremoving an LVM1 snapshot. > Internal error: LV snap1 (00000000000000000000000000000001) missing from preload metadata https://bugzilla.redhat.com/891855	Alasdair G Kergon	11 years ago
7307	lvmetad: add basic client-side debug logging lvmetad: add basic client-side debug logging First attempt at showing precisely what use any command is making of lvmetad in the -vvvv trace information.	Alasdair G Kergon	11 years ago
7306	lvmetad: rename device vars and move _token_update lvmetad: rename device vars and move _token_update Move _token_update() to avoid the need for _lvmetad_send prototype. Use 'dev' consistently for a struct device * variable. Use 'devno' for a dev_t.	Alasdair G Kergon	11 years ago
7305	libdaemon: add logging to daemon_open libdaemon: add logging to daemon_open Log all conditions encountered in daemon_open(). Only store errno when known to be set.	Alasdair G Kergon	11 years ago
7304	lvmetad: improve client logging when connecting lvmetad: improve client logging when connecting Rename lvmetad_warning() to lvmetad_connect_or_warn(). Log all connection attempts on the client side, whether successful or not. Reduce some nesting and remove a redundant assertion.	Alasdair G Kergon	11 years ago
7303	lvmetad: lvm depends on libdaemonclient.a lvmetad: lvm depends on libdaemonclient.a Rebuild lvm binary if libdaemonclient.a changes.	Alasdair G Kergon	11 years ago
7302	pvscan: synchronize with udev if pvscan --cache is used. pvscan: synchronize with udev if pvscan --cache is used. We need to call sync_local_dev_names directly as pvscan uses VG_GLOBAL lock and this one does not cause the synchronization (sync_dev_names) to be called on unlock (VG_GLOBAL is not a real VG): define unlock_vg(cmd, vol) do { \ if (is_real_vg(vol)) \ sync_dev_names(cmd); \ (void) lock_vol(cmd, vol, LCK_VG_UNLOCK); \ } while (0) Without this fix, we end up without udev synchronization for the pvscan --cache (mainly for -aay that causes the VGs/LVs to be autoactivated) and also udev synchronization cookies are then left in the system since they're not managed properly (code before sets up udev sync cookies, but we have to call dm_udev_wait at least once after that to do the wait and cleanup).	Peter Rajnoha	11 years ago
7301	activation: fix autoactivation to not trigger on each PV cha... activation: fix autoactivation to not trigger on each PV change Before, the pvscan --cache -aay was called on each ADD and CHANGE uevent (for a device that is not a device-mapper device) and each CHANGE event (for a PV that is a device-mapper device). This causes troubles with autoactivation in some cases as CHANGE event may originate from using the OPTION+="watch" udev rule that is defined in 60-persistent-storage.rules (part of the rules provided by udev directly) and it's used for all block devices (except fd\|mtd\|nbd\|gnbd\|btibm\|dm-\|md* devices). For example, the following sequence incorrectly activates the rest of LVs in a VG if one of the LVs in the VG is being removed: [root@rhel6-a ~]# pvcreate /dev/sda Physical volume "/dev/sda" successfully created [root@rhel6-a ~]# vgcreate vg /dev/sda Volume group "vg" successfully created [root@rhel6-a ~]# lvcreate -l1 vg Logical volume "lvol0" created [root@rhel6-a ~]# lvcreate -l1 vg Logical volume "lvol1" created [root@rhel6-a ~]# vgchange -an vg 0 logical volume(s) in volume group "vg" now active [root@rhel6-a ~]# lvs LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert lvol0 vg -wi------ 4.00m lvol1 vg -wi------ 4.00m [root@rhel6-a ~]# lvremove -ff vg/lvol1 Logical volume "lvol1" successfully removed [root@rhel6-a ~]# lvs LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert lvol0 vg -wi-a---- 4.00m ...so the vg was deactivated, then lvol1 removed, and we end up with lvol1 removed (which is ok) BUT with lvol0 activated (which is wrong)!!! This is because after lvol1 removal, we need to write metadata to the underlying device /dev/sda and that causes the CHANGE event to be generated (because of the WATCH udev rule set on this device) and this causes the pvscan --cache -aay to be reevaluated. We have to limit this and call pvscan --cache -aay to autoactivate VGs/LVs only in these cases: --> if the PV is not a dm device, scan only after proper device addition (ADD event) and not with any other changes (CHANGE event) --> if the PV is a dm device, scan only after proper mapping activation (CHANGE event + the underlying PV in a state "just activated")	Peter Rajnoha	11 years ago
7300	RAID: Limit replacement of devices when array is not in-syn... RAID: Limit replacement of devices when array is not in-sync. If a RAID array is not in-sync, replacing devices should not be allowed as a general rule. This is because the contents used to populate the incoming device may be undefined because the devices being read where not in-sync. The kernel enforces this rule unless overridden by not allowing the creation of an array that is not in-sync and includes a devices that needs to be rebuilt. Since we cannot know the sync state of an LV if it is inactive, we must also enforce the rule that an array must be active to replace devices. That leaves us with the following conditions: 1) never allow replacement or repair of devices if the LV is in-active 2) never allow replacement if the LV is not in-sync 3) allow repair if the LV is not in-sync, but warn that contents may not be recoverable. In the case where a user is performing the repair on the command line via 'lvconvert --repair', the warning is printed before the user is prompted if they would like to replace the device(s). If the repair is automated (i.e. via dmeventd and policy is "allocate"), then the device is replaced if possible and the warning is printed.	Jonathan Brassow	11 years ago
7299	WHATS_NEW: changelog for fae1a611d2 and 5294a6f77a WHATS_NEW: changelog for fae1a611d2 and 5294a6f77a	Peter Rajnoha	11 years ago
7298	lvm2app: No special behavior for 0 for max_snap_size in lvm_... lvm2app: No special behavior for 0 for max_snap_size in lvm_lv_snapshot() It isn't possible to choose a sane default for snapshot size, so just play it straight and use the passed size instead of adding special behavior for 0. Also revert change to Python lib, size parameter must be supplied. Signed-off-by: Andy Grover <agrover@redhat.com>	Andy Grover	11 years ago
7297	Revert "lvmetad: simplify pvid memory allocation." Revert "lvmetad: simplify pvid memory allocation." This reverts commit ed23da95b63308e11f8d680b189686a5d2d380d0. Hash table device_to_pvid seems to contain references to already deleted pvids and so revert to the older behaviour using allocated memory.	Zdenek Kabelac	11 years ago
7296	lvmetad: Fix a possible race in remove_metadata. lvmetad: Fix a possible race in remove_metadata. All operations on shared hash tables need to be protected by mutexes. Moreover, lookup and subsequent key removal need to happen atomically, to avoid races (and possible double free-ing) between multiple threads trying to manipulate the same VG.	Petr Rockai	11 years ago
7295	lvmetad: Fix a possible deadlock. lvmetad: Fix a possible deadlock. If an update and a query were running in parallel, there was a slim but non-zero chance of a deadlock due to (unnecessary) mutex nesting.	Petr Rockai	11 years ago
7294	lvmetad: simplify pvid memory allocation. lvmetad: simplify pvid memory allocation. Since pvid_dup and cft config appears to be tightly binded together - reuse it's memory pool for string. Simplifies release of hashes.	Zdenek Kabelac	11 years ago
7293	thin: dmeventd fix memleak on error path thin: dmeventd fix memleak on error path Some error paths on _umount have leaked bitset.	Zdenek Kabelac	11 years ago
7292	pv_read: add missing check for valid info pv_read: add missing check for valid info If the lvmcache_info_from_pvid() fails to find valid info, invoke the lookup by dev, and only in this case call lvmcache_info_from_pvid() again. Also check for the result of info and return error directly, so the NULL is not passed to lvmcache_get_label().	Zdenek Kabelac	11 years ago
7291	lvmetad: add check for failure dm_config_write_node lvmetad: add check for failure dm_config_write_node Detect if dm_config_write_node failed and fail correctly.	Zdenek Kabelac	11 years ago
7290	lvmetad: fix socket leak in handle_connect lvmetad: fix socket leak in handle_connect Close socket_fd and report error on malloc failure.	Zdenek Kabelac	11 years ago

Older »