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@xxxxxxxxxxxxxx> wrote:
[dropping stgt-devel@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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
