[OpenAFS-devel] [grand.central.org #124130] Re-opening the discussion (fwd)

Derrick Brashear shadow@gmail.com
Tue, 10 Mar 2009 08:24:12 -0500


On Tue, Mar 10, 2009 at 3:02 AM, Felix Frank <Felix.Frank@desy.de> wrote:
> On Mon, 9 Mar 2009, Jeffrey Altman wrote:
>
>> We need a new AFSFetchStatus64 (and everything else that has a time) so
>> that we can support 64-bit time values. =A0The question is what else do =
we
>> need to add? =A0We can always add new RPC values when we add new
>> functionality. =A0Doing so provides a built in negotiation mechanism:
>>
>> * clients only ask for what they support
>> * servers only send what they support
>>
>> The question is simply what are all of the things we know today that
>> need to go into the new RPCs and writing a proposal document to be
>> sent to afs3-stds so that the protocol discussion can take place.
>> The protocol is not limited to OpenAFS.
>
> I like the way this is going. I'm not quite sure whether you're saying we
> need to draft an extension to the whole protocol (I think you're not).
> In any case, I propose we come up with the AFSFetchStatus64 + RPCs sooner
> rather than later, speaking in the interest of OSD integration.
> We might even economize on design thoroughness by including sufficient sp=
are
> space in the struct, no?
>
> I don't know whether this thread is an appropriate place to gather needed
> fields. Regardless, this is what I can see so far:
>
> struct AFSFetchStatus {
> =A0 =A0afs_uint32 InterfaceVersion;
> =A0 =A0afs_uint32 FileType;
> =A0 =A0afs_uint32 LinkCount;
> =A0 =A0afs_uint64 Length;
> =A0 =A0afs_uint64 DataVersion;
> =A0 =A0afs_uint32 Author;
> =A0 =A0afs_uint32 Owner;
> =A0 =A0afs_uint32 CallerAccess;
> =A0 =A0afs_uint32 AnonymousAccess;
> =A0 =A0afs_uint32 UnixModeBits;
> =A0 =A0afs_uint32 ParentVnode;
> =A0 =A0afs_uint32 ParentUnique;
> =A0 =A0afs_uint32 ResidencyMask; =A0 /* is this needed? cscope tells me o=
f 3
> places
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 chang=
ing this, but none reading it */
> =A0 =A0afs_uint64 ClientModTime;
> =A0 =A0afs_uint64 ServerModTime;
> =A0 =A0afs_uint64 LastVolChangeTime; /* I don't know what this is truly c=
alled
> */
> =A0 =A0afs_uint32 Group;
> =A0 =A0afs_uint32 Protocol;
> =A0 =A0afs_uint32 lockCount;
> =A0 =A0afs_uint32 errorCode;
> =A0 =A0afs_uint32 spare[39]; =A0 /* -> 64 DWORDs */
> };
>
> Should memory alignment in 64-bit environments be considered (i.e., shoul=
d
> uint64s appear at "even" positions in the struct)?

I'd assume some way of representing per-file ACLs will appear, but i'd
have to think harder what you'd want to use to represent it.