[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180604132731.GA31515@redhat.com>
Date: Mon, 4 Jun 2018 09:27:31 -0400
From: Mike Snitzer <snitzer@...hat.com>
To: Christoph Hellwig <hch@....de>
Cc: Johannes Thumshirn <jthumshirn@...e.de>,
Hannes Reinecke <hare@...e.de>, Jens Axboe <axboe@...nel.dk>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
Linux NVMe Mailinglist <linux-nvme@...ts.infradead.org>,
Laurence Oberman <loberman@...hat.com>,
Sagi Grimberg <sagi@...mberg.me>,
James Smart <james.smart@...adcom.com>,
Ewan Milne <emilne@...hat.com>,
Linux Kernel Mailinglist <linux-kernel@...r.kernel.org>,
Keith Busch <keith.busch@...el.com>,
Martin George <marting@...app.com>,
John Meneghini <John.Meneghini@...app.com>,
dm-devel@...hat.com, mwilck@...e.de,
Benjamin Marzinski <bmarzins@...hat.com>
Subject: Re: [PATCH 0/3] Provide more fine grained control over multipathing
On Mon, Jun 04 2018 at 8:59am -0400,
Christoph Hellwig <hch@....de> wrote:
> On Mon, Jun 04, 2018 at 09:18:29AM +0200, Johannes Thumshirn wrote:
> > What we really should do is, try to give multipath-tools a 'nvme
> > list-subsys' like view of nvme native multipathing (and I think Martin
> > W. has already been looking into this a while ago).
>
> Which has been merged into multipath-tools a while ago:
>
> https://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=commit;h=86553b57b6bd55e0355ac27ae100cce6cc42bee3
And this is what I heard from Ben Marzinski last week:
Yeah. Things like
multipath -l
multipathd show maps
multipathd show paths
are supported. There is no support for the individual "show map" and
"show path" commands. Those only work on dm devices. There is also no
json formatting option for the foreign devices, but that could be added.
And probably will need to be, since people like RHEV really want to
use the library interface to multipathd with json formatted output.
Although if there are no dm multipath devices, there is no point to
running multipathd, so it might be worthwhile thinking about a library
interface to getting the information directly, instead of through
multipathd. That's a bigger rewrite.
Powered by blists - more mailing lists