Re: Clarification for Persistent Reservation + All Registrants

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2014-12-12 at 14:59 -0800, Nicholas A. Bellinger wrote:
> Hello T10/SCSI folks,
> 
> A question came up on the LIO target-devel mailing list recently wrt the
> proper handling of Persistent Reservations + All Registrants logic in a
> couple of different scenarios.

I can tell you how it was originally designed over a decade ago to
support clustering products (being in the business then of negotiating
with the manufacturers).

> The crux of the confusion stems from how registrations are treated
> before an explicit PR-OUT RESERVE service action with All Registrants
> type occurs, and after that explicit PR-OUT RESERVE of All Registrants
> type has been released.
> 
> My original interpretation was that an explicit PR-OUT RESERVE with All
> Registrants type had to first occur before other non reservation holding
> registrations (existing or not) would gain the implicit reservation.

You seem to be asking in the presence of registrations would an
unregistered initiator receive a reservation conflict before the PR_OUT
RESERVE is issued?  The answer, categorially is no because there's no
reservation until a registered initiator establishes one.

> This was primarily because the reservation type was not known until the
> explicit PR-OUT RESERVE occurred, and AFAICT at the time there where no
> host implementations that actually specified the reservation type at
> registration time.
> 
> So Is it correct to assume that one explicit PR-OUT RESERVE with All
> Registrants type needs to occur before other non reservation holding
> registrations gain an implicit reservation..?

I don't understand what you mean implicit reservation.  Once an all
registrants reservation is established, *all* registered initiators
become the reservation holder ... they're all equal.  This is mandated
in SPC-3 5.6.9

> How about when the explicit reservation is removed..?  Do the implicit
> reservations need to remain in effect for the existing registrations,
> even though the explicit reservation of All Registrants type no longer
> exists..?

Again, I don't understand the distinction between implicit and explicit.
For an all registrants reservation, all registered initiators are the
reservation holder so any one of them may release the reservation.  Once
the reservation is released, there's no reservation at all.

> The second point that Ilias raised is what should be the correct
> R_HOLDER bit status for PRIN READ_FULL_STATUS descriptors when All
> Registrants type is specified.  My original interpretation was that
> R_HOLDER was to signal the explicit reservation holder obtained with
> PR-OUT RESERVE, and not for the implicit reservations from the other
> registrations.  Is this the correct approach..?

R_HOLDER is set for any initiator that would be defined to be the
persistent reservation holder in section 5.6.9

> Also, does anyone have any experience with a host side implementation of
> All Registrants to use as a reference for what's already out in the
> wild..?

I know what was negotiated to support clustering (which is a pretty tiny
subset).  However, I think your point of confusion is trying to
distinguish between what you call implicit and explicit reservations ...
there's no such thing.  There's only a reservation holder which may be
many initiators, So it's binary: a given initiator either is or is not
the reservation holder.  Section 5.6 needs to be read in that context.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux