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

Matt Benjamin matt@linuxbox.com
Fri, 13 Mar 2009 14:09:02 -0400


I sense we don't want to ACL info (whether or not per-file) in
AFSFetchStatus64...

Since you bring that up, what the cache managers do now to cache access
control information (axsache) doesn't rely on the specific access list
that might be on an object, right?  A cache manager can get this
information, but it does so only to permit ACLs to be displayed and
edited.  So when we specified this aspect of per-file ACLs for GSOC, we
were assuming that notionally doesn't change, just ACLs may be
associated with file objects as well.  So clarifying, are you (Derrick)
thinking of a different model for client caching of access control
information than we currently have?

Tom notes (IM, maybe he'll join in) that a RPC union may allow us to
make structs like this more flexible (and avoid large spare array)--we
used it in extended callbacks and want to use the idea more.

Matt

Derrick Brashear wrote:
>>
>> 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 {
>>    afs_uint32 InterfaceVersion;
>>    afs_uint32 FileType;
>>    afs_uint32 LinkCount;
>>    afs_uint64 Length;
>>    afs_uint64 DataVersion;
>>    afs_uint32 Author;
>>    afs_uint32 Owner;
>>    afs_uint32 CallerAccess;
>>    afs_uint32 AnonymousAccess;
>>    afs_uint32 UnixModeBits;
>>    afs_uint32 ParentVnode;
>>    afs_uint32 ParentUnique;
>>    afs_uint32 ResidencyMask;   /* is this needed? cscope tells me of 3
>> places
>>                                   changing this, but none reading it */
>>    afs_uint64 ClientModTime;
>>    afs_uint64 ServerModTime;
>>    afs_uint64 LastVolChangeTime; /* I don't know what this is truly called
>> */
>>    afs_uint32 Group;
>>    afs_uint32 Protocol;
>>    afs_uint32 lockCount;
>>    afs_uint32 errorCode;
>>    afs_uint32 spare[39];   /* -> 64 DWORDs */
>> };
>>
>> Should memory alignment in 64-bit environments be considered (i.e., should
>> 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.
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel




- --

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJuqDxJiSUUSaRdSURCL6FAJ93T1l865I4kHrN1m1C+tkhozKh3gCfeqLk
kvdt3uBh6p+VpZ3JqS8SmNE=
=gqME
-----END PGP SIGNATURE-----