Re: [PATCH] storage: Ignore block devices that fail format detection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 30, 2015 at 11:13:21AM -0400, John Ferlan wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1276198
> 
> Prior to commit id '98322052' failure to saferead the block device would
> cause an error to be logged and the device to be skipped while attempting
> to discover/create a stable target path for a new LUN (NPIV).
> 
> This was because virStorageBackendSCSIFindLUs ignored errors from
> processLU and virStorageBackendSCSINewLun.
> 
> Ignoring the failure allowed a multipath device with an "active" and
> "ghost" to be present on the host with the "ghost" block device being
> ignored. This patch will return a -2 to the caller indicating the desire
> to ignore the block device since it cannot be used directly rather than
> fail the pool startup.
> 
> Additionally, it was found during some debugging that it was possible
> for the virStorageBackendDetectBlockVolFormatFD to not detect a format,
> which while not a probably - we probably should at least add some sort
> of warning message.
> 
> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
> ---
>  src/storage/storage_backend.c      | 4 ++++
>  src/storage/storage_backend_scsi.c | 7 ++++++-
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
> index a375fe0..2de606f 100644
> --- a/src/storage/storage_backend.c
> +++ b/src/storage/storage_backend.c
> @@ -1393,6 +1393,10 @@ virStorageBackendDetectBlockVolFormatFD(virStorageSourcePtr target,
>          }
>      }
>  
> +    if (target->format == VIR_STORAGE_POOL_DISK_UNKNOWN)
> +        VIR_WARN("cannot determine the target format for '%s'",
> +                 target->path);
> +
>      return 0;
>  }
>  

This change is unrelated to the other one. Also, is this warning really
needed? I think leaving the format as 'unknown' is visible enough.

> diff --git a/src/storage/storage_backend_scsi.c b/src/storage/storage_backend_scsi.c
> index a593a2b..d60473d 100644
> --- a/src/storage/storage_backend_scsi.c
> +++ b/src/storage/storage_backend_scsi.c
> @@ -224,9 +224,14 @@ virStorageBackendSCSINewLun(virStoragePoolObjPtr pool,
>          goto cleanup;
>      }
>  
> +    /* Failing to process the format is not fatal - we'll just skip
> +     * this volume.
> +     */
>      if (virStorageBackendUpdateVolInfo(vol, true,
> -                                       VIR_STORAGE_VOL_OPEN_DEFAULT) < 0)
> +                                       VIR_STORAGE_VOL_OPEN_DEFAULT) < 0) {
> +        retval = -2;
>          goto cleanup;

Adding the VIR_STORAGE_VOL_OPEN_NOERROR flag and propagating it down to
virStorageBackendDetectBlockVolFormatFD would be nicer.

That way it can return -2 on EIO if the flag is present without spamming
the logs. The other functions called by virStorageBackendUpdateVolInfo
can also return -1 on a fatal error that way (although there do not seem
to be any functions that could fail with NOERROR at the moment).

Jan

Attachment: signature.asc
Description: Digital signature

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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]