mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2025-01-21 20:15:17 +00:00
disk: Allow settling to occur after reading partitions
https://bugzilla.redhat.com/show_bug.cgi?id=1400475 In order to avoid a possible error as a result of kernel interactions with the partition helper, let's use virWaitForDevices to force things to settle down before attempting to open and read the partition. This is related to https://bugzilla.redhat.com/show_bug.cgi?id=1264719. Although perhaps overkill to have too many places to settle, since we know that the act of reading the partitions via libvirt_parthelper will cause udev activity/events - we just need to ensure udev has been settled before proceding with usage of the device. Signed-off-by: John Ferlan <jferlan@redhat.com> ACKed-by: Michal Privoznik <mprivozn@redhat.com>
This commit is contained in:
parent
509abc40d4
commit
e288080ae0
@ -183,7 +183,16 @@ virStorageBackendDiskMakeDataVol(virStoragePoolObjPtr pool,
|
||||
* after an extended partition is created an open on the extended
|
||||
* partition will fail, so pass the NOERROR flag and only error if a
|
||||
* -1 was returned indicating some other error than an open error.
|
||||
*
|
||||
* NB: A small window exists in some cases where the just created
|
||||
* partition disappears, but then reappears. Since we were given
|
||||
* vol->target.path from parthelper, let's just be sure that any
|
||||
* kernel magic that occurs as a result of parthelper doesn't cause
|
||||
* us to fail with some sort of ENOENT failure since that would be
|
||||
* quite "unexpected". So rather than just fail, let's use the
|
||||
* virWaitForDevices to ensure everything has settled properly.
|
||||
*/
|
||||
virWaitForDevices();
|
||||
if (vol->source.partType == VIR_STORAGE_VOL_DISK_TYPE_EXTENDED) {
|
||||
if (virStorageBackendUpdateVolInfo(vol, false,
|
||||
VIR_STORAGE_VOL_OPEN_DEFAULT |
|
||||
|
Loading…
x
Reference in New Issue
Block a user