On Fri, Oct 9, 2009 at 3:07 PM, Jeffrey Altman <[email protected]> wrote: > Andrew Deason wrote: >> On Fri, 9 Oct 2009 15:12:14 +0100 >> Simon Wilkinson <[email protected]> wrote: >> >>> Generic Quotas >>> -------------- >>> >>> Christof had raised the issue of providing a more generic quota >>> mechanism, which allows more flexible definitions of what quota might >>> be (rxosd would like to be able to apply a separate quota to files >>> under a certain size, for example) >>> >>> We discussed implementing this as a set of tag value pairs, with each >>> pair having a globally defined meaning. Individual tags need not be >>> implemented on every fileserver - there should be an RPC by which >>> clients can determine which tags a fileserver supports. We want to >>> implement this by revising existing RPCs which take quota values, and >>> use it to replace the quota values that those RPCs already contain. >>> >>> Christof will write a document describing this, but we won't block >>> the RPC refresh on it >> >> 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. >> > I believe that is what is being described by implementation via a set of > tag-value pairs where the set of tag names can be queried. >
As Jeff mentions, the tag-value pairs provide us with considerable generality (ignoring the TLV/unions debate for now). One note: we are making an effort to form a clear distinction between tag-value pairs that relate to durable metadata, and tag-value pairs that relate to volatile metadata/server state. Christof and Hartmut are working on standardization of the interface that is relevent to on-disk metadata, and I am responsible for designing the introspection interface for volatile state. I believe the rough consensus from Edinburgh is that tag-value pairs are appropriate for both mechanisms, which is how I'm planning to proceed for the first draft of the volume state I-D, barring objections. -Tom _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
