To: Black_David@emc.com Cc: Gerry.Houlder@seagate.com, t10@t10.org Subject: RE: Persistent Reservation Proposal - Group Reservations From: Kevin D Butt <kdbutt@us.ibm.com> Date: Thu, 3 Jan 2008 11:51:06 -0700 X-Message-Number: 8373 Formatted message: HTML-formatted message We looked at using the existing reservation key but could not make it work because, among other things, it is returned in PR In and it's behavior is assumed to be non unique by existing applications. For these reasons we did not spend too much time looking at it. IBM has one intent, but I found that there are at least two others, Roger Cummings and Fred Knight, that have different intents. Roger was thinking of bringing something similar in himself - though it is subtly different. I am not sure I understand all those subtleties. The basic intent I was aiming for is for use in the tape drives (making sure it is also good for disks). There is a need to have any reservation solidly exclusive to a given host. However, it is desirable to allow multiple HBA's on the same host to have that exclusive access. This allows for load balancing and failover internal to the same host. Add to that the need to allow for failover to a second host - also with multiple HBA's but guaranteeing that if whatever out of band communication is occurring between he two hosts fails that the two hosts will be protected from each other. That is, if somehow each host thinks it should have the access, the tape drive is still protected such that only one host at a time can have permission to access the drive. If host A thinks host B went away and steals the reservation (a la PREEMPT) host B will no longer have permission and will get a UA next time it tries access. Add to this the ability for the tape drive to be shared in an open system and still have this work. In reality, this is nothing more than each HBA on a single host being able to share an exclusive reservation and no other initiator port can join in without the owner telling it how to. I sent another note planning a phone conference so we can clearly lay out the desired intent. Please respond to that note. Thanks, Kevin D. Butt SCSI & Fibre Channel Architect, Tape Firmware MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 Tel: 520-799-2869 / 520-799-5280 Fax: 520-799-2723 (T/L:321) Email address: kdbutt@us.ibm.com http://www-03.ibm.com/servers/storage/ Black_David@emc.com Sent by: owner-t10@t10.org 01/03/2008 07:19 AM To <Gerry.Houlder@seagate.com>, <t10@t10.org> cc Subject RE: Persistent Reservation Proposal - Group Reservations * From the T10 Reflector (t10@t10.org), posted by: * Black_David@emc.com * I'm still checking with our implementers, but my initial reaction is that Gerry's 2-for-2: (1) I strongly agree with Gerry's preference for a new RESERVATION type over a new REGISTRATION type. PR code is already subtle in a number of ways, and a new reservation type is much easier to isolate from existing types in specification, coding, and testing. It should also have better behavior when mixing implementations that don't all support the new functionality. We probably need two new types, one for group write and one for group exclusive. (2) Is there a reason why we can't use the existing reservation key as the entity that has to match for the new reservation type? One would have to ensure that the reservation key can't be read from the device by PR IN, but we already have the precedent (and the specification text) to do that in the All Registrants reservation types. Reuse of the reservation key is going to be easier to cope with than inventing a new group identifier. What initiator implementations are likely to use this new functionality for what purposes? Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: owner-t10@t10.org [mailto:owner-t10@t10.org] On Behalf > Of Gerry.Houlder@seagate.com > Sent: Wednesday, January 02, 2008 4:40 PM > To: t10@t10.org > Subject: RE: Persistent Reservation Proposal - Group Reservations > > * From the T10 Reflector (t10@t10.org), posted by: > * Gerry.Houlder@seagate.com > * > So this is Roger's preference: > > >1) Define a new type of REGISTER that contains one (or more) GRIDs; > >2) Extend RESERVE to include a single GRID, and only Initiators that have > registered (or will register) with a matching GRID get access under the > reservation; > >3) Don't change PREEMPT, superseding reservations etc. at all - keep the > rules for handling the reservation keys completely orthogonal to the GRID; > >4) Don't allow GRIDs to be accessed via PR In. > > If we don't add a new reservation type, it sounds like you are describing a > new registration type (existing one without GRID, new one with GRID). This > seems to complicate the rules for making an "all registrants" reservation. > If the initiator making the reservation specifies a GRID, only other > initiators that registered with that GRID value inherit the reservation and > the others are excluded. This would be a very different result for current > initiators that expect to inherit any reservations just by registering. > > Further, the "unexpectedly excluded" registered initiator will get no clue > as to why it doesn't inherit the reservation. if it issues READ RESERVATION > it gets back a response that says an all registrants reservation is in > force. The PR generation and reservation key values returned won't help any > either, and the GROUP ID value of course will not be returned. Creating a > new reservation type would help here, since the reservation type is > returned by READ RESERVATION. This might be an advantage of creating a new > reservation type for GRID Registrants Only (or something like that). The > new reservation type would make it more obvious why you didn't inherit a > reservation you expected to inherit. > > Also for backwards compatibility, will initiators be able to register with > existing method (i.e., not specifying a GROUP ID) as well as a new method > that specifies a GROUP ID? The standard will have to describe how > registrants without a group ID, registrants with a non-matching group ID, > and registrants with a matching group ID will interact with the current > registrants only reservation and a "GRID registrants only" reservation. > > Do we really lose that much if we simply create a "matching reservation > key" reservation instead? That means only initiators that register with a > matching reservation key inherit the reservation. We lose a little bit of > security because the matching ID value is publicly reported and a malicious > initiator can still join, but a malicous initiator could probably get > around the Group ID value match just by bute force retries anyway (how many > bytes of group ID is enough?), or just preempt the group ID reservation and > replace it with a regular registrants only reservation. This is a simpler > method of creating a Group ID reservation that probably works just fine for > co-operating initiators (as opposed to previously described malicious > ones). > > * > * For T10 Reflector information, send a message with > * 'info t10' (no quotes) in the message body to majordomo@t10.org > > * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo@t10.org