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

[Arne Redlich]

[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