On Thu, 2016-09-29 at 11:01 -0400, Mike Snitzer wrote:
> On Tue, Sep 27 2016 at 2:50pm -0400,
> James Bottomley wrote:
>
> > On Tue, 2016-09-27 at 08:34 +0200, Hannes Reinecke wrote:
> > > On 09/26/2016 09:06 PM, James Bottomley wrote:
> > > > On Mon, 2016-09-26 at 09:52 -0700, Christoph Hellwig
On Thu, Sep 29, 2016 at 11:01:33AM -0400, Mike Snitzer wrote:
> I've elected to just take this change for 4.9. Please see:
> https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.9&id=8ff232c1a819c2e98d85974a3bff0b7b8e2970ed
Thanks Mike.
If any problems show up I
On Tue, Sep 27 2016 at 2:50pm -0400,
James Bottomley wrote:
> On Tue, 2016-09-27 at 08:34 +0200, Hannes Reinecke wrote:
> > On 09/26/2016 09:06 PM, James Bottomley wrote:
> > > On Mon, 2016-09-26 at 09:52 -0700, Christoph Hellwig wrote:
> > > > Getting back to this after Hannes recovered from hi
On Tue, 2016-09-27 at 08:34 +0200, Hannes Reinecke wrote:
> On 09/26/2016 09:06 PM, James Bottomley wrote:
> > On Mon, 2016-09-26 at 09:52 -0700, Christoph Hellwig wrote:
> > > Getting back to this after Hannes recovered from his vacation
> > > and I had a chat with him..
> > >
> > > On Mon, Aug 1
On 09/26/2016 09:06 PM, James Bottomley wrote:
> On Mon, 2016-09-26 at 09:52 -0700, Christoph Hellwig wrote:
>> Getting back to this after Hannes recovered from his vacation
>> and I had a chat with him..
>>
>> On Mon, Aug 15, 2016 at 09:40:39AM -0400, Mike Snitzer wrote:
>>> Seems we still need a
On Mon, 2016-09-26 at 09:52 -0700, Christoph Hellwig wrote:
> Getting back to this after Hannes recovered from his vacation
> and I had a chat with him..
>
> On Mon, Aug 15, 2016 at 09:40:39AM -0400, Mike Snitzer wrote:
> > Seems we still need a more sophisticated approach. But I'm left
> > wonde
Getting back to this after Hannes recovered from his vacation
and I had a chat with him..
On Mon, Aug 15, 2016 at 09:40:39AM -0400, Mike Snitzer wrote:
> Seems we still need a more sophisticated approach. But I'm left
> wondering: if we didn't do it would anything notice? Sadly, the same
> big q
he LUN
> while we have a file system mounted, what error will we end up
> getting?
> I would assume that we would still see the usual SCSI error message
> with the CDB printed, and that the "reservation conflict" message was
> supplemental? Or does the message get
t can still be
> seen, just not usually.
>
> James
>
So, if we do this, and someone else does a SCSI-2 RESERVE on the LUN
while we have a file system mounted, what error will we end up getting?
I would assume that we would still see the usual SCSI error message
with the CDB print
On Tue, 2016-09-13 at 16:24 +0200, Hannes Reinecke wrote:
> On 09/13/2016 04:04 PM, James Bottomley wrote:
> > You could argue that the entire message needs removing, since it's
> > reporting stuff that mostly only shows when systems using
> > reservations correctly are in operation.
> >
> Oh, I'
On 09/13/2016 04:04 PM, James Bottomley wrote:
> On Mon, 2016-09-12 at 10:20 +0200, Hannes Reinecke wrote:
>> SPC-2 and SPC-3 (or later) differ in the handling of reservation
>> conflict for TEST UNIT READY. SPC-2 will return 'reservation
>> conflict', whereas SPC-3
On Mon, 2016-09-12 at 10:20 +0200, Hannes Reinecke wrote:
> SPC-2 and SPC-3 (or later) differ in the handling of reservation
> conflict for TEST UNIT READY. SPC-2 will return 'reservation
> conflict', whereas SPC-3 will return GOOD status.
> On a mixed system with both SPC-2
Sent: Monday, September 12, 2016 4:20:53 AM
> Subject: [PATCH] scsi: do not print 'reservation conflict' for TEST UNIT READY
>
> SPC-2 and SPC-3 (or later) differ in the handling of reservation
> conflict for TEST UNIT READY. SPC-2 will return 'reservation conflict',
>
SPC-2 and SPC-3 (or later) differ in the handling of reservation
conflict for TEST UNIT READY. SPC-2 will return 'reservation conflict',
whereas SPC-3 will return GOOD status.
On a mixed system with both SPC-2 and SPC-3 targets one will
see lots of 'reservation conflict' mes
ly that'd impose the use of a new
> 'conflict_seen' (or whatever) flag at the end of 'struct pgpath'. And
> then only return error if the flag is set.
>
> I threw together the following RFC patch to illustrate what I'm
> thinking, but thinking about this f
ollowing RFC patch to illustrate what I'm
thinking, but thinking about this further it is tough to know all paths
have seen the reservation conflict (my patch assumes if 'conflict_seen'
is set then the conflict iterated through all paths.. but if paths
aren't being failed there
ping?
On Tue, Aug 02, 2016 at 02:36:32PM +0200, Christoph Hellwig wrote:
> From: Hannes Reinecke
>
> If dm-mpath encounters an reservation conflict it should not fail the
> path (as communication with the target is not affected) but should
> rather retry on another path. However,
From: Hannes Reinecke
If dm-mpath encounters an reservation conflict it should not fail the
path (as communication with the target is not affected) but should
rather retry on another path. However, in doing so we might be inducing
a ping-pong between paths, with no guarantee of any forward
On 07/16/2015 09:54 AM, Christoph Hellwig wrote:
> On Thu, Jul 16, 2015 at 05:07:03AM +, Christophe Varoqui wrote:
>> For reference the opensvc crm does use type 5 pr, and aims for all paths
>> registered. It still does not make use of the multipathd pr janitoring
>> features, and uses sg_persi
On Thu, Jul 16, 2015 at 05:07:03AM +, Christophe Varoqui wrote:
> For reference the opensvc crm does use type 5 pr, and aims for all paths
> registered. It still does not make use of the multipathd pr janitoring
> features, and uses sg_persist directly for pr status and actions.
The type doesn
3 +0200, Hannes Reinecke wrote:
> >>>> If dm-mpath encounters an reservation conflict it should not
> >>>> fail the path (as communication with the target is not affected)
> >>>> but should rather retry on another path.
> >>>> However, in doing
On 07/15/2015 02:01 PM, James Bottomley wrote:
> On Wed, 2015-07-15 at 13:52 +0200, Hannes Reinecke wrote:
>> On 07/15/2015 01:35 PM, James Bottomley wrote:
>>> On Wed, 2015-07-15 at 13:23 +0200, Hannes Reinecke wrote:
>>>> If dm-mpath encounters an reservation confli
ch a need should arise we can add it
> and take that into account in the multipathing code.
>
Which was my reasoning as well.
I would consider a per-path reservation in a multipath setup an
error, as the current multipath code is not able to handle this.
With the current code we will fail a pat
On Wed, 2015-07-15 at 13:52 +0200, Hannes Reinecke wrote:
> On 07/15/2015 01:35 PM, James Bottomley wrote:
> > On Wed, 2015-07-15 at 13:23 +0200, Hannes Reinecke wrote:
> >> If dm-mpath encounters an reservation conflict it should not
> >> fail the path (as communica
An array can't issue a reservation, the initiator needs to register
it. Right now the only way to do it is through SG_IO passthrough,
which is a best luck effort it I/O isn't also using SG_IO and can't
be properly supported because of that.
However I will submit an in-kernel reservation API soon
On 07/15/2015 01:35 PM, James Bottomley wrote:
> On Wed, 2015-07-15 at 13:23 +0200, Hannes Reinecke wrote:
>> If dm-mpath encounters an reservation conflict it should not
>> fail the path (as communication with the target is not affected)
>> but should rather retry on another
On Wed, 2015-07-15 at 13:23 +0200, Hannes Reinecke wrote:
> If dm-mpath encounters an reservation conflict it should not
> fail the path (as communication with the target is not affected)
> but should rather retry on another path.
> However, in doing so we might be inducing a ping-
If dm-mpath encounters an reservation conflict it should not
fail the path (as communication with the target is not affected)
but should rather retry on another path.
However, in doing so we might be inducing a ping-pong between
paths, with no guarantee of any forward progress.
And arguably a
Hi,
It's the first time I used this list so I apologize if this is not the
right place for this question.
I have a SCSI drive already reserved by one host. Another host tries to
access it (with maybe TestUnitReady, Read ...). The device returns scsi
status of Reservation Conflict. My d
29 matches
Mail list logo
