[stgt] RFC [PATCH] Implement PERSISTENT RESERVE IN/OUT

[ronnie sahlberg]

Please try my tool i linked with earlier.

it can be used to
   read the list of registered keys
   register a particular key (with any scope / type you want)
   unregister keys
   report capabilities
   read the current set of reservations
   create a reservation
   clear a reservation
   preemt a reservation


it might be very useful for testing the persistent reservation code


On Thu, Aug 21, 2008 at 7:25 PM, Mark Harvey <markh794 at gmail.com> wrote:
> Arne Redlich wrote:
>>
>> [re-adding stgt list]
>>
>> Am Mittwoch, den 20.08.2008, 13:49 -0700 schrieb Richard Sharpe:
>>>
>>> On Wed, Aug 20, 2008 at 1:08 PM, Arne Redlich <agr at powerkom-dd.de> wrote:
>>>>
>>>> [dropping stgt-devel at berlios]
>>>>
>>>> Am Mittwoch, den 20.08.2008, 15:01 +1000 schrieb Mark Harvey:
>>>>>
>>>>> Apologies for sending as an attachment... gmail and all.
>>>>>
>>>> Though I'm not sure it will differ at all in this area, but SPC-3 should
>>>> be used as reference when implementing it - cf. spc_inquiry().
>>>
>>> I agree ...
>>>
>>>> [snip]
>>>>
>>>>> +struct scsi_pr {
>>>>> +     /* Persistent Reservation Generation */
>>>>> +     uint32_t PRgeneration;
>>>>> +     uint8_t pr_key[PR_RESERVATION_SZ][PR_KEY_SZ];
>>>>> +};
>>>>> +
>>>>
>>>> Too bad the most interesting part is missing - an efficient way to
>>>> lookup the registered keys. I could imagine using a hashtable, but then
>>>> again finding a good hash function is not easy - (u64)key % tablesize
>>>> possibly? So:
>>>
>>> However, for a first implementation, and given the nature of the usage
>>> of these commands, how efficient does this need to be?
>>>
>>> I could only imagine reservations being placed by say, no more than a
>>> dozen to two dozen initiators in an environment consisting of FC
>>> initiators and targets and so forth.
>>>
>>> What I am saying is I am having a hard time understanding why
>>> efficiency is a concern here, but maybe that is because I lack
>>> experience in the environments you deal with.
>
> It really needs to be checked for EVERY scsi command received by the lu. And
> then there is the 'exclusive' reservation vs any initiator with a registered
> key.
>
>>
>> Once a reservation is placed on the LU you have to check if a command
>> is allowed or whether it leads to a reservation conflict. And this is
>> done by looking at the registered keys, so you really want this lookup
>> to be as fast as possible.
>
> I plan on using the PRgeneration which appears to be updated each time
> something within the reservation status change.
>
> i.e. Most performance hit can be over-come by storing the 'last
> PRgeneration' and if it is greater, then do the intensive checks.
>
> Unfortunately, until I get enough of the code in place - I won't really know
> :)
>
>
> As for testing, I have the ability to check using Veritas Cluster Server &
> NetBackup.
>
>>
>> Cheers,
>> Arne
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe stgt" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe stgt" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html