summaryrefslogtreecommitdiffstats
path: root/tools
diff options
context:
space:
mode:
authorPeter Rajnoha <prajnoha@redhat.com>2012-04-11 09:12:02 +0000
committerPeter Rajnoha <prajnoha@redhat.com>2012-04-11 09:12:02 +0000
commit30bd294fc6b310e7d59ed7b0f654257f3b202c9c (patch)
tree23ee920a13ad747323fd9b40476980ab77f217dd /tools
parentc0b5886f18ffe21e1f32acf3ac7b1ba05b0abede (diff)
downloadlvm2-30bd294fc6b310e7d59ed7b0f654257f3b202c9c.tar.gz
lvm2-30bd294fc6b310e7d59ed7b0f654257f3b202c9c.tar.xz
lvm2-30bd294fc6b310e7d59ed7b0f654257f3b202c9c.zip
Change message severity to log_very_verbose for missing dev info in udev db.
Libudev does not provide transactions when querying udev database - once we get the list of block devices (devices/obtain_device_list_from_udev=1) and we iterate over the list to get more detailed information about device node and symlink names used etc., the device could be removed just in between we get the list and put a query for more info. In this case, libudev returns NULL value as the device does not exist anymore. Recently, we've added a warning message to reveal such situations. However, this could be misleading if the device is not related to the LVM action we're just processing - the non-related block device could be removed in parallel and this is not an error but a possible and normal operation. (N.B. This "missing info" should not happen when devices are related to the LVM action we're just processing since all such processing should be synchronized with udev and the udev db must always be in consistent state after the sync point. But we can't filter this situation out from others, non-related devices, so we have to lower the message verbosity here for a general solution.)
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions