[AFS3-std] AFSVol Tag-Length-Value extensions I-D

Derrick Brashear shadow@gmail.com
Sat, 18 Dec 2010 23:23:37 -0500


On Sat, Dec 18, 2010 at 11:19 PM, Tom Keiser <tkeiser@gmail.com> wrote:
> On Dec 17, 2010 11:17 PM, "Matt W. Benjamin" <matt@linuxbox.com> wrote:
>>
>> Hi Tom,
>>
>> I've read the tag-length-value draft specification multiple times quickl=
y,
>> and once carefully. =A0Though I'm not expert in volser, the proposed pro=
tocol
>> seems very coherent and reasonable.
>>
>> Though it's a nit, I find some of the long token constants (e.g.,
>> "VOLSERTAGUNSUPPORTEDENCODING") hard to read. =A0It might be nice to bre=
ak up
>> the token namespace with understores (e.g.,
>> "VOLSER_TAG_UNSUPPORTED_ENCODING"), if the token length exceeds some min=
umum
>> (14 characters seems plausible)? =A0This is already done for most token
>> namespaces in the draft.
>>
>
> Sounds good.=A0 I'll make the necessary changes for draft -04.
>
>> I wondered also if the tag cache coherence ambiguity could be helped
>> through the use of some type of data version or serialization token in
>> relevant calls?
>>
>
> Hmm.=A0 That's an interesting idea.=A0 Proposal: If we were to add an OUT
> parameter to each Get...TLV RPC, which communicated the generation number
> for the tag namespace, then--combined with rx epoch checks--the caller wo=
uld
> know when to re-fetch the list of available tags.
>
> Although I doubt this issue is likely to come up very often in the real
> world, an additional four byte payload hardly seems objectionable...
>
> Does that sound reasonable and sufficient?=A0 If so, I can incorporate th=
e
> idea into draft -04...
>
> Thanks very much for the feedback.

That sounds like an excellent plan to me.