From: Xose Vazquez Perez <xose.vazquez@gmail.com>
To: Martin Wilck <mwilck@suse.com>, Hannes Reinecke <hare@suse.de>,
Brian Bunker <brian@purestorage.com>,
Benjamin Marzinski <bmarzins@redhat.com>,
John Garry <john.g.garry@oracle.com>,
Wayne Berthiaume <Wayne.Berthiaume@dell.com>,
Yanfei Chen <vincent.chen1@dell.com>, heyi <yi.he@dell.com>,
Nigel Hislop <hislop_nigel@dell.com>,
NetApp RDAC team <ng-eseries-upstream-maintainers@netapp.com>,
Steven Schremmer <Steve.Schremmer@netapp.com>,
Martin George <marting@netapp.com>,
Matthias Rudolph <Matthias.Rudolph@hitachivantara.com>
Cc: DM-DEVEL ML <dm-devel@lists.linux.dev>,
SCSI ML <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 0/1] checkers: add alua path checker
Date: Thu, 12 Mar 2026 22:05:18 +0100 [thread overview]
Message-ID: <2fb4a070-607a-4e59-9766-e793d4af49f6@gmail.com> (raw)
In-Reply-To: <bc54bb449129d0a026e69a502d82ef54793f33cc.camel@suse.com>
On 3/12/26 5:48 PM, Martin Wilck wrote:
> Actually, multipathd could use TUR for checking unless we receive an
> event of this type. multipathd could listen to those events and then
> retrieve the new device state(s) from sysfs, without sending an RTPG
> command itself.
>
> We wouldn't switch to the alua checker by default anyway, so the
> vendors that prefer the sysfs prioritizer won't be hurt even
> if that doesn't work.
Just one observation: currently there are ALUA arrays (NetApp E/EF, Dell Unity)
where their own checker is preferred.
As well as software-defined storage (Hitachi Vantara VSP One SDS Block, Linux-IO
(LIO) Target) where directio must be used.
parent reply other threads:[~2026-03-12 21:05 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <bc54bb449129d0a026e69a502d82ef54793f33cc.camel@suse.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2fb4a070-607a-4e59-9766-e793d4af49f6@gmail.com \
--to=xose.vazquez@gmail.com \
--cc=Matthias.Rudolph@hitachivantara.com \
--cc=Steve.Schremmer@netapp.com \
--cc=Wayne.Berthiaume@dell.com \
--cc=bmarzins@redhat.com \
--cc=brian@purestorage.com \
--cc=dm-devel@lists.linux.dev \
--cc=hare@suse.de \
--cc=hislop_nigel@dell.com \
--cc=john.g.garry@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--cc=marting@netapp.com \
--cc=mwilck@suse.com \
--cc=ng-eseries-upstream-maintainers@netapp.com \
--cc=vincent.chen1@dell.com \
--cc=yi.he@dell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox