Re: [PATCH 22/30] multipath: Implement 'property' blacklist

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

 



On Fri, Nov 07, 2014 at 10:04:40AM +0100, Bart Van Assche wrote:
> On 08/21/14 21:31, Hannes Reinecke wrote:
> >On 08/21/2014 06:37 PM, Bart Van Assche wrote:
> >>Hannes Reinecke <hare <at> suse.de> writes:
> >>>Multipath can only handle device properly which support the VPD
> >>>page 0x83. Originally this was ensured by 'scsi_id', which would
> >>>not present an ID_SERIAL value in these cases.
> >>>With the move to udev 'ID_SERIAL' is now always present, so
> >>>multipath would try to attach to _all_ SCSI devices.
> >>>This patch implements an 'property' blacklist, which allows to
> >>>blacklist a device based on the existence of udev properties.
> >>>Any device not providing the udev property from the whitelist
> >>>will be ignored.
> >>>The default whitelist is set to '(ID_WWN|ID_SCSI_VPD)'.
> >>>
> >>>[ ... ]
> >>
> >>(replying to an e-mail of one year ago)
> >>
> >>Hello Hannes,
> >>
> >>I have a question about this patch. Which software component should
> >>set the
> >>ID_SCSI_VPD parameter ? Is it udev, now integrated in systemd ? I'm
> >>asking
> >>this because I haven't found any patch in the udev nor in the systemd
> >>repositories that sets the ID_SCSI_VPD parameter. Does this mean that
> >>another parameter should be used to restore support for SCSI devices that
> >>support the VPD page 0x83 but do not report a WWN in that page ? Or does
> >>this mean that systemd should be modified such that it sets the
> >>ID_SCSI_VPD parameter ?
> >
> >That's actually simple typo. ID_SCSI_VPD was generated by one of the
> >earlier instances of the sg3_utils udev rules.
> >It should read 'SCSI_IDENT_LUN', as this is what the current udev rules
> >from sg3_utils generate.
> >I have a patch queued in my sles12 patchset; but so far haven't found
> >time to clean them up and send upstream.
> >Will be doing so once sles12 is done...
> 
> (replying to an e-mail of two months ago)
> 
> Hello Hannes,
> 
> Have you already been able to free up some time to revisit what has been
> discussed above ?
> 
> Thanks,
> 
> Bart.

I don't know if you're interested, but I had some requests to allow
multipath on devices that really aren't multipathable. People wanted it
because the liked the user_friendly persistent names and the ability to
not automatically fail up IO errors. So, I have a patch that simply
removes the property blacklist_exception default, and makes it so that
if not property blacklist_exception is given, then devices aren't failed
for not matching it.  You could then set this in the default
multipath.conf file, but then users have to option to delete it.

I'm not sure how much of a niche use this is for multipath, so I didn't
bother to post it, but I can if people are interested.

-Ben

> 
> --
> dm-devel mailing list
> dm-devel@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/dm-devel

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




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux