On 02/24/2011 12:26 AM, Philipp Hahn wrote:
If you use '[PATCHv3] subject' instead of '[PATCH] subject (v3)', then
'git am' won't include the (v3) as part of the commit message (a good
thing, since once the patch is upstream, no one cares any longer if it
took three revisions to be ready for upstream).
Currently a single storage volume with a broken backing file will disable the
whole storage pool. This can happen when the backing file is on some
unavailable network storage or if the backing volume is deleted, while the
storage volumes using it are not.
Since the storage pool then can not be re-activated, re-creating the missing
or
deleting the now useless volumes using libvirt only is impossible.
To "fix" this case, all errors detected during storage pool activation are now
(silently) ignored. Errors are still logged by the called functions, which
have
more knowledge on the detailed error condition.
diff --git a/src/storage/storage_backend_fs.c b/src/storage/storage_backend_fs.c
index ff39d48..0cf4e54 100644
--- a/src/storage/storage_backend_fs.c
+++ b/src/storage/storage_backend_fs.c
@@ -647,11 +647,11 @@ virStorageBackendFileSystemRefresh(virConnectPtr conn
ATTRIBUTE_UNUSED,
&vol->allocation,
&vol->capacity,
&vol->target.encryption)) < 0)
{
- if (ret == -1)
- goto cleanup;
- else {
- /* Silently ignore non-regular files,
- * eg '.' '..', 'lost+found', dangling symbolic
link */
+ if (ret < 0) {
+ /* Silently ignore all errors,
+ * eg '.' '..', 'lost+found', dangling symbolic
link,
+ * backend file unavailable, file unreadable.
+ * A detailed error report has already been logged. */
virStorageVolDefFree(vol);
vol = NULL;
continue;
Hmm, is this fix really right? Or should we be fixing
virStorageBackendProbeTarget to handle missing backing files in the same
way that it handles dangling symlinks (by returning -2), while still
warning the user about real errors (when returning -1)?
I think that it makes sense to create a directory pool no matter how
botched the contents of the directory are, but would like a second
opinion from someone more familiar with the storage pool code before
committing this (danpb is probably most qualified).
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org