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 |