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.

Signed-off-by: John Ferlan <jferlan@redhat.com>
---

 NB: This also resolves issues seen while testing the patch with using
     pool-refresh "frequently" on the disk pool. Perhaps the timing of
     things has changed enough that it'd be see more often now. At least
     with the f26 test system I used.

     BTW: The other option proposed long ago, but rejected was adding
     a timeout loop.  I've also run the python script from the other
     bz with 100% success.

 src/storage/storage_backend_disk.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c
index 7b4549c34d..2e3d1e04a4 100644
--- a/src/storage/storage_backend_disk.c
+++ b/src/storage/storage_backend_disk.c
@@ -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 |
-- 
2.14.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 05/24/2018 05:43 PM, John Ferlan wrote:
> 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.
> 
> Signed-off-by: John Ferlan <jferlan@redhat.com>
> ---
> 
>  NB: This also resolves issues seen while testing the patch with using
>      pool-refresh "frequently" on the disk pool. Perhaps the timing of
>      things has changed enough that it'd be see more often now. At least
>      with the f26 test system I used.
> 
>      BTW: The other option proposed long ago, but rejected was adding
>      a timeout loop.  I've also run the python script from the other
>      bz with 100% success.
> 
>  src/storage/storage_backend_disk.c | 9 +++++++++
>  1 file changed, 9 insertions(+)

ACK

Michal

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list