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.
Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
---
src/storage/storage_backend.c | 4 ++++
src/storage/storage_backend_disk.c | 32 +++++++++++++++++++++++---------
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
index b990a82..d7bccfe 100644
--- a/src/storage/storage_backend.c
+++ b/src/storage/storage_backend.c
@@ -1385,6 +1385,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;
diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c
index 31b6025..233e293 100644
--- a/src/storage/storage_backend_disk.c
+++ b/src/storage/storage_backend_disk.c
@@ -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;
--
2.1.0
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list