Linux Device Mapper development
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Mike Christie <michael.christie@oracle.com>,
	linux-block@vger.kernel.org,  dm-devel@redhat.com,
	snitzer@kernel.org, hch@lst.de, axboe@kernel.dk,
	martin.petersen@oracle.com,
	james.bottomley@hansenpartnership.com,
	linux-scsi@vger.kernel.org, target-devel@vger.kernel.org
Subject: Re: [dm-devel] [PATCH 0/8] Use block pr_ops in LIO
Date: Sat, 4 Jun 2022 21:01:30 -0700	[thread overview]
Message-ID: <923053d3-adf8-e4b4-9ef3-8e920ae90a79@acm.org> (raw)
In-Reply-To: <20220603065536.5641-1-michael.christie@oracle.com>

On 6/2/22 23:55, Mike Christie wrote:
> The following patches were built over Linus's tree. They allow us to use
> the block pr_ops with LIO's target_core_iblock module to support cluster
> applications in VMs.
> 
> Currently, to use something like windows clustering in VMs with LIO and
> vhost-scsi, you have to use tcmu or pscsi or use a cluster aware
> FS/framework for the LIO pr file. Setting up a cluster FS/framework is
> pain and waste when your real backend device is already a distributed
> device, and pscsi and tcmu are nice for specific use cases, but iblock
> gives you the best performance and allows you to use stacked devices
> like dm-multipath. So these patches allow iblock to work like pscsi/tcmu
> where they can pass a PR command to the backend module. And then iblock
> will use the pr_ops to pass the PR command to the real devices similar
> to what we do for unmap today.
> 
> Note that this is patchset does not attempt to support every PR SCSI
> feature in iblock. It has the same limitations as tcmu and pscsi where
> you can have a single I_T nexus per device and only supports what is
> needed for windows clustering right now.

How has this patch series been tested? Does LIO pass the libiscsi 
persistent reservation tests with this patch series applied?

Thanks,

Bart.

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


  parent reply	other threads:[~2022-06-05  4:01 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-03  6:55 [dm-devel] [PATCH 0/8] Use block pr_ops in LIO Mike Christie
2022-06-03  6:55 ` [dm-devel] [PATCH 01/11] scsi: target: Rename sbc_ops to exec_cmd_ops Mike Christie
2022-06-20  7:12   ` Christoph Hellwig
2022-06-03  6:55 ` [dm-devel] [PATCH 02/11] scsi: Rename sd_pr_command Mike Christie
2022-06-20  7:13   ` Christoph Hellwig
2022-06-03  6:55 ` [dm-devel] [PATCH 03/11] scsi: Move sd_pr_type to header to share Mike Christie
2022-06-05  3:58   ` Bart Van Assche
2022-06-20  7:13   ` Christoph Hellwig
2022-06-03  6:55 ` [dm-devel] [PATCH 04/11] block: Add PR callouts for read keys and reservation Mike Christie
2022-06-20  7:14   ` Christoph Hellwig
2022-06-03  6:55 ` [dm-devel] [PATCH 05/11] scsi: Add support for block PR read keys/reservation Mike Christie
2022-06-03  6:55 ` [dm-devel] [PATCH 06/11] dm: " Mike Christie
2022-06-03  6:55 ` [dm-devel] [PATCH 07/11] scsi: target: Allow backends to hook into PR handling Mike Christie
2022-06-20  7:15   ` Christoph Hellwig
2022-06-03  6:55 ` [dm-devel] [PATCH 08/11] scsi: target: Add block PR support to iblock Mike Christie
2022-06-20  7:18   ` Christoph Hellwig
2022-06-03  6:55 ` [dm-devel] [PATCH 09/11] block, nvme: Add error for reservation conflicts Mike Christie
2022-06-03 19:45   ` Keith Busch
2022-06-03 23:08     ` Mike Christie
2022-06-04  7:38     ` Hannes Reinecke
2022-06-04 17:13       ` michael.christie
2022-06-05  9:42         ` Hannes Reinecke
2022-06-20  7:23           ` Christoph Hellwig
2022-06-05  4:00   ` Bart Van Assche
2022-06-03  6:55 ` [dm-devel] [PATCH 10/11] scsi: Use BLK_STS_RSV_CONFLICT " Mike Christie
2022-06-03  6:55 ` [dm-devel] [PATCH 11/11] scsi: target: Handle BLK_STS_RSV_CONFLICT Mike Christie
2022-06-03 11:46 ` [dm-devel] [PATCH 0/8] Use block pr_ops in LIO Christoph Hellwig
2022-06-03 17:55   ` Mike Christie
2022-06-20  7:12     ` Christoph Hellwig
2022-06-05  4:01 ` Bart Van Assche [this message]
2022-06-05 16:55   ` Mike Christie
2022-06-05 18:15     ` Bart Van Assche
2022-06-06 16:38       ` Mike Christie

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=923053d3-adf8-e4b4-9ef3-8e920ae90a79@acm.org \
    --to=bvanassche@acm.org \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=hch@lst.de \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=michael.christie@oracle.com \
    --cc=snitzer@kernel.org \
    --cc=target-devel@vger.kernel.org \
    /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