<div dir="ltr">I was waiting to see your response to Ben's comment about the pref bit default values and tunable.</div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Jun 3, 2016 at 9:05 AM, Hannes Reinecke <<a href="mailto:hare@suse.de" target="_blank">hare@suse.de</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On 05/31/2016 10:34 PM, Sebastian Herbszt wrote: > Hannes Reinecke wrote: >> Recent kernels have an 'access_state' attribute which allows >> us to read the asymmetric access state directly from sysfs. >> >> Signed-off-by: Hannes Reinecke <<a href="mailto:hare@suse.de">hare@suse.de</a>> >> --- >> libmultipath/discovery.c | 33 +++++++++++++++++++++++++++++ >> libmultipath/discovery.h | 2 ++ >> libmultipath/prio.h | 1 + >> libmultipath/prioritizers/Makefile | 3 ++- >> libmultipath/prioritizers/sysfs.c | 43 ++++++++++++++++++++++++++++++++++++++ >> libmultipath/propsel.c | 6 +++++- >> multipath/multipath.conf.5 | 14 ++++++++++++- >> 7 files changed, 99 insertions(+), 3 deletions(-) >> create mode 100644 libmultipath/prioritizers/sysfs.c > > How about just adding this to the alua prioritizer? > This new feature could then depend on a "sysfs" argument. > No. The 'sysfs' prioritizer is using the abstract kernel sysfs interface, for which every device handler provides the information. So in theory it's independent on the underlying device handler. However, only the ALUA device handler has been reworked to provide up-to-date information; for the other device handlers there is a risk of the sysfs information is getting out-of-date. Hence I've restricted the 'detect_prioritizer' algorithm to select 'sysfs' only if an ALUA system is present. But this doesn't imply in any way that the 'sysfs' prioritizer can be used only for ALUA systems. Christophe, what about merging the patch? Cheers, Hannes </blockquote></div> </div>