[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. 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. 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 |