Re: [libvirt] [PATCH] Shorten the udevadm settle timeout for refresh/start pool cases

https://bugzilla.redhat.com/show_bug.cgi?id=789766 This patch addresses a possible misperception that libvirt is hung during pool startup/refresh as well as virt-manager startup as it needs to start/refresh storage pools found. The problem is that the 'udevadm settle' command will wait for a default of two minutes prior to returning a failure. For code paths such as pool starts or refreshes the timeout doesn't necessarily cause failures - it may just not find anything. Additionally, since no error message or any other indication is proviced, blame is placed up libvirt for the problem; however, use of debug tools shows libvirt waiting in udevadm. NB: This timeout may be longer for iSCSI and SCSI pools since both seem to run through settle paths twice under certain conditions. Based on feedback described here: http://lists.freedesktop.org/archives/systemd-devel/2013-July/011845.html this timeout is part of the architecture of udevadm settle. Although the two minute timeout expires, the code doesn't check status. Callers can decide to continue regardless of whether settle is still handling events.

For paths waiting for something specific, failure will be inevitable; however, for paths such as perhaps pool refreshes waiting for "anything" to be present within the directory space udevadm manages having a shorter timeout may allow them to gather some data quicker/sooner. It's always possible to refresh the data again at some later point.

For paths that are waiting for something specific, such as finding a node device, creating a backing disk volume, or removing a logical volume waiting longer for settle to work through its events will be more important. So given this, I modified the calls to virFileWaitForDevices() pass a boolean 'quiesce' indicating whether the caller should wait for the default timeout or to wait a shorter time. I chose 5 seconds for the shorter time, although there was no real logic/reason for it. Additionally, for either case use VIR_WARN to indicate that the command to settle the database returned a failure. --- Note that I did try to use a timeout value of 0 which as I was reading things would somehow indicate that something needed to be flushed; however, for the veth issue described here: http://lists.freedesktop.org/archives/systemd-devel/2013-July/011829.html the return value of a udevadm settle --timeout 0 was always 0; whereas, if using --timeout 1 (or more) the return value was 1. Callers to virFileWaitForDevices() and my reasoning/logic behind why I chose to wait for quiesce or not... node_device_driver -> Is trying to find node devices - wait long time storage_backend_*.c: (virStorageBackend*() APIs) disk: DiskRefreshPool -> Will read directory path - wait short time disk: DiskCreateVol -> Requires new disk to be present - wait long time iscsi: ISCSIGetHostNumber -> called by ISCSIFindLUs which is called by RefreshPool before opening path and scanning for devices - wait short time logical: LogicalRefreshPool -> Runs /usr/sbin/vgs to get report of volume groups - wait short time logical: LogicalDeleteVol -> Requires synchronization prior to deletion of logical volume - wait long time mpath: MpathRefreshPool -> Use DM_DEVICE_LIST to get list of devices - wait short time scsi: SCSIFindLUs -> called by SCSIRefreshPool and ISCSIFindLUs (not sure why) prior to opening path and scanning for available devices - wait short time scsi: createVport -> called by SCSIStartPool after the port is managed - there's no search for any devices and nothing depends on or checks if the port was created (although next call in sequence would be to refresh the pool, which would wait again) - wait short time Signed-off-by: John Ferlan <jferlan(a)redhat.com&gt; --- src/node_device/node_device_driver.c | 4 ++-- src/storage/storage_backend_disk.c | 4 ++-- src/storage/storage_backend_iscsi.c | 2 +- src/storage/storage_backend_logical.c | 4 ++-- src/storage/storage_backend_mpath.c | 2 +- src/storage/storage_backend_scsi.c | 4 ++-- src/util/virfile.h | 2 +- src/util/virutil.c | 45 +++++++++++++++++++++++++++-------- 8 files changed, 46 insertions(+), 21 deletions(-)