[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aCQibkfVcvRDCzsG@infradead.org>
Date: Tue, 13 May 2025 21:56:14 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Benjamin Marzinski <bmarzins@...hat.com>
Cc: Christoph Hellwig <hch@...radead.org>, Hannes Reinecke <hare@...e.de>,
Kevin Wolf <kwolf@...hat.com>, Martin Wilck <mwilck@...e.com>,
dm-devel@...ts.linux.dev, hreitz@...hat.com, mpatocka@...hat.com,
snitzer@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] dm mpath: Interface for explicit probing of active
paths
On Tue, May 13, 2025 at 12:29:51PM -0400, Benjamin Marzinski wrote:
> Without reading that sense and status information in kernel, the
> multipath target can't know if it needs to fail a path and retry the
> ioctl down a different path. QEMU can read this information, but it
> doesn't know what path the multipath device send the ioctl down. This
> patch just gives users a way to check the paths in the active pathgroup
> (which all should be able to handle IO) and fail those that can't.
> While QEMU is the driver of this, it's completely general functionality.
As just replied to Martin the problem is that this setup fundamentally
can't work. Either you pass a SCSI devices through, which should
(mostly, there are a few warts) work. Or you want host side
multipathing, in which case you must pass through the block device
abstraction and not a SCSI one, or at least do a full emulation of
the SCSI interfaces instead of pretending to pass it through.
The root of all evil here is that dm-multipath tries to pass through
SG_IO, which is dangerous for all but the most trivial commands.
Powered by blists - more mailing lists