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

Re: [dm-devel] [PATCH] multipathd: Don't mark a virtio_blk path offline if it has no sysfs "state" attribute



On Thu, 05 May 2011 09:02:07 +0200, Hannes Reinecke <hare suse de>
wrote:

> path_offline() _absolutely_ requires a check if the device is 
> actually a SCSI device. We do have several others to contend with 
> (cciss, dasd), and none of those do have the 'state' attribute.
> 
> So we need this patch
> 
> diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
> index 6cd2ec9..4af0cd3 100644
> --- a/libmultipath/discovery.c
> +++ b/libmultipath/discovery.c
> @@ -645,6 +645,10 @@ path_offline (struct path * pp)
>          struct sysfs_device * parent;
>          char buff[SCSI_STATE_SIZE];
> 
> +       if (pp->bus != SYSFS_BUS_SCSI)
> +               /* No information for non-SCSI devices, return UP */
> +               return PATH_UP;
> +
>          pp->sysdev = sysfs_device_from_path(pp);
>          if (!pp->sysdev) {
>                  condlog(1, "%s: failed to get sysfs information", 
> pp->dev);


That sure works for me...  ;-)

> And you need to implement virtio_blk as it's own bus type.
> (Say SYSFS_BUS_VIRTIO). And teach discovery.c to detect this one 
> properly.
> Look at 'cciss' and 'dasd' on how that's done.

Have to?  Currently it all works!  :-)

Devices with bus SYSFS_BUS_UNDEF seem to work just fine - someone
seems to have made a conscious decision to make it so in the past. I
don't get a vendor/model or anything else very useful listed against
my paths, but multipath works fine...

Do you think that's an acceptable way of operating or should we
definitely put some code in to give virtio_blk a bus type?  My personal
opinion is that it is OK as it is.

Thanks...

peace & happiness,
martin

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