[AFS3-std] Re: Hackathon Summary

[Andrew Deason]

On Fri, 9 Oct 2009 21:59:45 +0200
Christof Hanke <christof.hanke@rzg.mpg.de> wrote:

> Am Freitag, 9. Oktober 2009 19:22:46 schrieb Andrew Deason:
> >
> > Upon reading this, I thought, why should we limit this to quotas?
> > Should we have a more generic extensible volume metadata RPC that
> > can be used for any volume-related purpose? I would imagine an
> > xattr-like functionality at the volume level could be potentially
> > useful for numerous things.
> 
> It was not meant for quotas only, but also for usage.
> We agreed just to change the volintInfo-structure for that.

Yes, sorry, I see now I was just misreading it.

> Thus, basically the tags to be used which are obvious for me now are :
> * block-usage 
> * block-quota
> * file-usage
> * file-quota
> 
> which can be all of the same type (afs_uint64).
> 
> Something more generic would mean to support more data-types than
> afs_uint64, which could be done using the techniques for dumping the
> volume, but I'm not sure if we should do all that in one step.

Well, at the very least, I'd like for it to be possible to include other
datatypes in the future, without having to create a new RPC. Either
unions or XDR opaques is what I would think, but hey, you're the one
designing it.

In particular, the use case I'm thinking of is for specifying per-volume
ACL policies, to control who is able to set what ACLs; a more general
solution to the problem gerrit 217 was trying to solve. We don't have a
full spec for it yet, but I know it would certainly require more than
just an afs_uint64 payload.

One other thing that would help me out with that is an optional
tag-specific parameter to the 'get' RPC (so I can get the ACL policy for
a particular user). Using strings instead of the normal integers for
tags would also solve this (and would be even closer to xattrs), but I
don't know if that's desirable.
 
Also, another possible idea I thought of is a way in the 'set' RPC to
set the specified tag for all volumes currently on the server. It's not
really critical; more of a convenience/performance enhancement, since
it's possible to just enumerate the volumes yourself and set each one.

-- 
Andrew Deason
adeason@sinenomine.net