Re: Persistent Reservation API V4

On Wed, Oct 28 2015 at 2:43pm -0400, Mike Snitzer wrote: > On Thu, Oct 15 2015 at 8:10am -0400, > Christoph Hellwig wrote: > > > This series adds support for a simplified Persistent Reservation API > > to the block layer. The intent is that both in-kernel and userspace

Re: Persistent Reservation API V4

On Thu, Oct 15 2015 at 8:10am -0400, Christoph Hellwig wrote: > This series adds support for a simplified Persistent Reservation API > to the block layer. The intent is that both in-kernel and userspace > consumers can use the API instead of having to hand craft SCSI or NVMe > com

Re: Persistent Reservation API V4

On Thu, Oct 15 2015 at 8:10am -0400, Christoph Hellwig <h...@lst.de> wrote: > This series adds support for a simplified Persistent Reservation API > to the block layer. The intent is that both in-kernel and userspace > consumers can use the API instead of having to hand cra

Re: Persistent Reservation API V4

On Wed, Oct 28 2015 at 2:43pm -0400, Mike Snitzer <snit...@redhat.com> wrote: > On Thu, Oct 15 2015 at 8:10am -0400, > Christoph Hellwig <h...@lst.de> wrote: > > > This series adds support for a simplified Persistent Reservation API > > to the block layer.

Re: [dm-devel] [PATCH 3/6] sd: implement the Persistent Reservation API

On Thu, Oct 15, 2015 at 08:30:50AM -0700, Bart Van Assche wrote: > Can you explain why this functionality has been added to the sd driver > instead of the SCSI core ? Aren't persistent reservations a concept that > applies to all SCSI device types ? In theory it does. In practice it's only

Re: [dm-devel] [PATCH 3/6] sd: implement the Persistent Reservation API

On 10/15/2015 05:10 AM, Christoph Hellwig wrote: This is a mostly trivial mapping to the PERSISTENT RESERVE IN/OUT commands. Hello Christoph, Can you explain why this functionality has been added to the sd driver instead of the SCSI core ? Aren't persistent reservations a concept that

[PATCH 3/6] sd: implement the Persistent Reservation API

This is a mostly trivial mapping to the PERSISTENT RESERVE IN/OUT commands. Signed-off-by: Christoph Hellwig --- drivers/scsi/sd.c | 96 +++ 1 file changed, 96 insertions(+) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index

Persistent Reservation API V4

This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through interfaces. It also adds DM support as getting

Persistent Reservation API V4

This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through interfaces. It also adds DM support as getting

[PATCH 3/6] sd: implement the Persistent Reservation API

This is a mostly trivial mapping to the PERSISTENT RESERVE IN/OUT commands. Signed-off-by: Christoph Hellwig --- drivers/scsi/sd.c | 96 +++ 1 file changed, 96 insertions(+) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c

Re: [dm-devel] [PATCH 3/6] sd: implement the Persistent Reservation API

On Thu, Oct 15, 2015 at 08:30:50AM -0700, Bart Van Assche wrote: > Can you explain why this functionality has been added to the sd driver > instead of the SCSI core ? Aren't persistent reservations a concept that > applies to all SCSI device types ? In theory it does. In practice it's only

Re: [dm-devel] [PATCH 3/6] sd: implement the Persistent Reservation API

On 10/15/2015 05:10 AM, Christoph Hellwig wrote: This is a mostly trivial mapping to the PERSISTENT RESERVE IN/OUT commands. Hello Christoph, Can you explain why this functionality has been added to the sd driver instead of the SCSI core ? Aren't persistent reservations a concept that

Re: Persistent Reservation API V3

On Fri, Aug 28, 2015 at 08:33:24PM -0500, Jeremy Linton wrote: > Hello, > So, looking at this, I don't see how it supports the algorithm I've > been using > for years. For that algorithm to successfully migrate PRs across multiple > paths > on a single machine without affecting other

Re: Persistent Reservation API V3

On Fri, Aug 28, 2015 at 08:33:24PM -0500, Jeremy Linton wrote: Hello, So, looking at this, I don't see how it supports the algorithm I've been using for years. For that algorithm to successfully migrate PRs across multiple paths on a single machine without affecting other possible

Re: Persistent Reservation API V3

is extremely dangerous in any environment where actual arbitration or sharing of the resource is taking place. thanks, On 8/26/2015 11:56 AM, Christoph Hellwig wrote: > This series adds support for a simplified Persistent Reservation API > to the block layer. The intent is tha

Re: Persistent Reservation API V3

is extremely dangerous in any environment where actual arbitration or sharing of the resource is taking place. thanks, On 8/26/2015 11:56 AM, Christoph Hellwig wrote: This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both

[PATCH 3/5] sd: implement the Persistent Reservation API

This is a mostly trivial mapping to the PERSISTENT RESERVE IN/OUT commands. Signed-off-by: Christoph Hellwig --- drivers/scsi/sd.c | 94 +++ 1 file changed, 94 insertions(+) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index

Persistent Reservation API V3

This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through interfaces. It also adds DM support as getting

Re: Persistent Reservation API V3

Meh, looks like the train wifi is too bad to send out a whole patch series. I'll resend once I've arrived.. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at

Persistent Reservation API V3

This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through interfaces. It also adds DM support as getting

Persistent Reservation API V3

This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through interfaces. It also adds DM support as getting

[PATCH 3/5] sd: implement the Persistent Reservation API

This is a mostly trivial mapping to the PERSISTENT RESERVE IN/OUT commands. Signed-off-by: Christoph Hellwig h...@lst.de --- drivers/scsi/sd.c | 94 +++ 1 file changed, 94 insertions(+) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index

Persistent Reservation API V3

This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through interfaces. It also adds DM support as getting

Persistent Reservation API V3

This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through interfaces. It also adds DM support as getting

Re: Persistent Reservation API V3

Meh, looks like the train wifi is too bad to send out a whole patch series. I'll resend once I've arrived.. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at

Persistent Reservation API V3

This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through interfaces. It also adds DM support as getting

Re: Persistent Reservation API V2

On Thu, Aug 20, 2015 at 11:56:36PM +, Keith Busch wrote: > NVMe can also specify > if whether or not a reservation should persist through power-loss. SCSI does as well, it's the APTPL flag. However reservations not persistent through a power loss are basically useless, so I decided to force

Re: Persistent Reservation API V2

On Thu, Aug 20, 2015 at 11:56:36PM +, Keith Busch wrote: NVMe can also specify if whether or not a reservation should persist through power-loss. SCSI does as well, it's the APTPL flag. However reservations not persistent through a power loss are basically useless, so I decided to force

Re: Persistent Reservation API V2

On Tue, 11 Aug 2015, Christoph Hellwig wrote: This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through

Re: Persistent Reservation API V2

On Tue, 11 Aug 2015, Christoph Hellwig wrote: This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through

Re: Persistent Reservation API V2

On 08/17/2015 01:13 PM, Christoph Hellwig wrote: Does this look fine to you Jens? I'd love to get this API into 4.3 so I can submit the NFS SCSI layout patches that depend on it for 4.4. I'll take a look at this today. -- Jens Axboe -- To unsubscribe from this list: send the line

Re: Persistent Reservation API V2

On 08/17/2015 01:13 PM, Christoph Hellwig wrote: Does this look fine to you Jens? I'd love to get this API into 4.3 so I can submit the NFS SCSI layout patches that depend on it for 4.4. I'll take a look at this today. -- Jens Axboe -- To unsubscribe from this list: send the line

Re: Persistent Reservation API V2

Does this look fine to you Jens? I'd love to get this API into 4.3 so I can submit the NFS SCSI layout patches that depend on it for 4.4. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: Persistent Reservation API V2

Does this look fine to you Jens? I'd love to get this API into 4.3 so I can submit the NFS SCSI layout patches that depend on it for 4.4. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at

Persistent Reservation API V2

This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through interfaces. It also adds DM support as getting

[PATCH 3/5] sd: implement the Persistent Reservation API

This is a mostly trivial mapping to the PERSISTENT RESERVE IN/OUT commands. Signed-off-by: Christoph Hellwig --- drivers/scsi/sd.c | 90 +++ 1 file changed, 90 insertions(+) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index

[PATCH 3/5] sd: implement the Persistent Reservation API

This is a mostly trivial mapping to the PERSISTENT RESERVE IN/OUT commands. Signed-off-by: Christoph Hellwig h...@lst.de --- drivers/scsi/sd.c | 90 +++ 1 file changed, 90 insertions(+) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index

Persistent Reservation API V2

This series adds support for a simplified Persistent Reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through interfaces. It also adds DM support as getting

Re: Persistent Reservation API

On Tue, Aug 04, 2015 at 06:04:04PM +, Keith Busch wrote: > On Tue, 4 Aug 2015, Christoph Hellwig wrote: >> NVMe support currently isn't included as I don't have a multihost >> NVMe setup to test on, but if I can find a volunteer to test it I'm >> happy to write the code for it. > > Looks

Re: Persistent Reservation API

On Tue, Aug 04, 2015 at 01:53:49PM -0400, Mike Snitzer wrote: > The DM changes need to go through linux-dm.git. Once the block and SCSI > bits land I'll rebase accordingly. That cross-maintainer logisitics > aside, I'll reply with feedback on the DM patches. That sounds fine to me, thanks! --

Re: Persistent Reservation API

On Tue, Aug 04, 2015 at 06:04:04PM +, Keith Busch wrote: On Tue, 4 Aug 2015, Christoph Hellwig wrote: NVMe support currently isn't included as I don't have a multihost NVMe setup to test on, but if I can find a volunteer to test it I'm happy to write the code for it. Looks pretty good so

Re: Persistent Reservation API

On Tue, Aug 04, 2015 at 01:53:49PM -0400, Mike Snitzer wrote: The DM changes need to go through linux-dm.git. Once the block and SCSI bits land I'll rebase accordingly. That cross-maintainer logisitics aside, I'll reply with feedback on the DM patches. That sounds fine to me, thanks! -- To

Re: Persistent Reservation API

On Tue, 4 Aug 2015, Christoph Hellwig wrote: NVMe support currently isn't included as I don't have a multihost NVMe setup to test on, but if I can find a volunteer to test it I'm happy to write the code for it. Looks pretty good so far. I'd be happy to give try it out with NVMe subsystems. --

Re: Persistent Reservation API

On Tue, Aug 04 2015 at 3:11am -0400, Christoph Hellwig wrote: > This series adds support for a simplified persistent reservation API > to the block layer. The intent is that both in-kernel and userspace > consumers can use the API instead of having to hand craft SCSI or NVMe > com

Persistent Reservation API

This series adds support for a simplified persistent reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through interfaces. It also adds DM support as getting

Persistent Reservation API

This series adds support for a simplified persistent reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command through the various pass through interfaces. It also adds DM support as getting

Re: Persistent Reservation API

On Tue, 4 Aug 2015, Christoph Hellwig wrote: NVMe support currently isn't included as I don't have a multihost NVMe setup to test on, but if I can find a volunteer to test it I'm happy to write the code for it. Looks pretty good so far. I'd be happy to give try it out with NVMe subsystems. --

Re: Persistent Reservation API

On Tue, Aug 04 2015 at 3:11am -0400, Christoph Hellwig h...@lst.de wrote: This series adds support for a simplified persistent reservation API to the block layer. The intent is that both in-kernel and userspace consumers can use the API instead of having to hand craft SCSI or NVMe command