]> xenbits.xensource.com Git - libvirt.git/commitdiff
storage: Adjust how to refresh extended partition disk data
authorJohn Ferlan <jferlan@redhat.com>
Thu, 22 Jan 2015 14:12:04 +0000 (09:12 -0500)
committerJohn Ferlan <jferlan@redhat.com>
Wed, 28 Jan 2015 22:28:03 +0000 (17:28 -0500)
During virStorageBackendDiskMakeDataVol processing, if we find an extended
partition, then handle it specially when updating the capacity/allocation
rather than calling virStorageBackendUpdateVolInfo.

As it turns out, once a logical partition exists, any attempt to refresh
the pool or after libvirtd restart/reload will result in a failure to open
the extended partition device resulting in the inability to start the pool.
The downside to this is we will lose the <permissions> and <timestamps> for
the extended partition upon subsequent restart, refresh, reload since the
stat() in virStorageBackendUpdateVolTargetInfoFD will not be called. However,
since it's really only a container and shouldn't directly be used for
storage that seems reasonable.

Therefore, only use the existing code that already had a comment about
getting the allocation wrong for extended partitions for just the setting
of the extended partition data.

src/storage/storage_backend.c
src/storage/storage_backend_disk.c

index 4e6dcc3c148d343d8e3c8d97f47193fd30355515..a67d50cb3385cb788eebc3fdceb4078b40a1a527 100644 (file)
@@ -1438,6 +1438,10 @@ virStorageBackendVolOpen(const char *path, struct stat *sb,
             VIR_WARN("ignoring missing file '%s'", path);
             return -2;
         }
+        if (errno == ENXIO && noerror) {
+            VIR_WARN("ignoring missing fifo '%s'", path);
+            return -2;
+        }
 
         virReportSystemError(errno, _("cannot open volume '%s'"), path);
         return -1;
index 31b6025d1e0390bb29397f0a4545382fe1d6eaca..233e293dd597ed240143add36b7c17a041898b97 100644 (file)
@@ -110,11 +110,6 @@ virStorageBackendDiskMakeDataVol(virStoragePoolObjPtr pool,
             return -1;
     }
 
-    /* Refresh allocation/capacity/perms */
-    if (virStorageBackendUpdateVolInfo(vol, true, false,
-                                       VIR_STORAGE_VOL_OPEN_DEFAULT) < 0)
-        return -1;
-
     /* set partition type */
     if (STREQ(groups[1], "normal"))
        vol->source.partType = VIR_STORAGE_VOL_DISK_TYPE_PRIMARY;
@@ -127,10 +122,29 @@ virStorageBackendDiskMakeDataVol(virStoragePoolObjPtr pool,
 
     vol->type = VIR_STORAGE_VOL_BLOCK;
 
-    /* The above gets allocation wrong for
-     * extended partitions, so overwrite it */
-    vol->target.allocation = vol->target.capacity =
-        (vol->source.extents[0].end - vol->source.extents[0].start);
+    /* Refresh allocation/capacity/perms
+     *
+     * For an extended partition, virStorageBackendUpdateVolInfo will
+     * return incorrect values for allocation and capacity, so use the
+     * extent information captured above instead.
+     *
+     * Also once a logical partition exists or another primary partition
+     * 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.
+     */
+    if (vol->source.partType == VIR_STORAGE_VOL_DISK_TYPE_EXTENDED) {
+        if (virStorageBackendUpdateVolInfo(vol, true, false,
+                                           VIR_STORAGE_VOL_OPEN_DEFAULT |
+                                           VIR_STORAGE_VOL_OPEN_NOERROR) == -1)
+            return -1;
+        vol->target.allocation = vol->target.capacity =
+            (vol->source.extents[0].end - vol->source.extents[0].start);
+    } else {
+        if (virStorageBackendUpdateVolInfo(vol, true, false,
+                                           VIR_STORAGE_VOL_OPEN_DEFAULT) < 0)
+            return -1;
+    }
 
     if (STRNEQ(groups[2], "metadata"))
         pool->def->allocation += vol->target.allocation;