[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <265961162cf0747a82c66c6cae38aecb85acfec9.camel@suse.com>
Date: Tue, 13 May 2025 10:17:58 +0200
From: Martin Wilck <mwilck@...e.com>
To: Christoph Hellwig <hch@...radead.org>, Hannes Reinecke <hare@...e.de>
Cc: Kevin Wolf <kwolf@...hat.com>, dm-devel@...ts.linux.dev,
hreitz@...hat.com, mpatocka@...hat.com, snitzer@...nel.org,
bmarzins@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] dm mpath: Interface for explicit probing of active
paths
On Mon, 2025-05-12 at 23:49 -0700, Christoph Hellwig wrote:
> On Tue, May 13, 2025 at 08:32:12AM +0200, Hannes Reinecke wrote:
> > Reservations and stuff.
>
> They should use the kernel persistent reservation API.
>
> > There are customer who use GPFS ...
>
> Supporting illegal binary only modules that is already enough of a
> reason to NAK this.
GPFS is not the only use case.
The reason why we have "scsi-block" in qemu is simply SCSI emulation.
If we emulate a SCSI device to a VM, the device should support commands
like persistent reservations properly. "scsi-block" supports this,
while still offering decent IO performance to VMs. In the multipath
case, the idea is to be able to hide from the VM the fact that the
device in question is actually a multipath device, and still allow this
sort of SCSI commands to be passed through to the storage.
And no, passing the SCSI devices to the VM and doing multipath in the
the guest doesn't work. The transport layer isn't properly emulated
(bluntly speaking, we have no FC emulation).
Regards
Martin
Powered by blists - more mailing lists