- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Fri, 12 Dec 2003 10:32:10 +0100
- To: Chris Sharp <csharp@apple.com>
- Cc: w3c-dist-auth@w3.org, Brian Korver <briank@xythos.com>
Chris, I agree to your analysis that the current definitions lead to confusion. The way out is to simplify the underlying model. Definition: a "quota space" is a storage area on the server where allocation can be restricted. All collections on a server either belong to a particular quota space or to no quota space at all (in which case storage allocation, if possible, in such collections cannot be controlled by quotas). Corollary1: all collections of a particular quota space report the same values for their DAV:quota* properties. Corollary2: all resources belong to the same quota space as their parent collection(s). Corollary3: all collections which may contain bindings to the same resource do belong to the same quota space. Collections in different quota spaces cannot have bindings to the same resource. With this model, /A and /A/UploadDirectory will either have the same DAV:quota* values or totally unrelated ones, depending if the two collections belong to the same or to different quota spaces. Thus the problem of "it does not sum up" is avoided. Also, server side implementation can be much simpler, as the hiearchies (e.g. bindings) of collections and resources do *not* influence the quota values. //Stefan Am 11.12.2003 um 19:30 schrieb Chris Sharp: > Just getting around to understanding this thread. I totally agree, the > quota-assigned-bytes seems unnecessary and confusing. > > On another note, I think there needs to be some clarification the way > quota-available-bytes and quota-used-bytes work. > > Example: > > Initial State of Repository with a Quota management system: > > > DAV:quota-available-bytes DAV:quota-used-bytes > /A 95MB > 5MG <--- used for somewhere for > something > /A/UploadDirectory 10MB > 0 > > A new 5MB resource is created at /A/UploadDirectory/new5MBFile: > > DAV:quota-available-bytes DAV:quota-used-bytes > /A 90MB > 10MB > /A/UploadDirectory 5MB > 5MB > > Pretty clear, however, if there is no quota differentiation on > /A/UploadDirectory, the current draft of the RFC makes > quota-used-bytes, which is really inherited from its parent, > incongruent with quota-available-bytes on the same resource. A diagram > is in order: > > Initial State of Repository with a Quota management system: > (quota system on /A only) > > DAV:quota-available-bytes DAV:quota-used-bytes > /A 95MB > 5MG > > A new 5MB resource is created at /A/UploadDirectory/new5MBFile: > > DAV:quota-available-bytes DAV:quota-used-bytes > /A 90MB > 10MB > /A/UploadDirectory 90MB > 5MB > > The sum of quota-available-bytes and quota-used-bytes is 95 on > /A/UploadDirectory and not 100! Logically, if you get a request for > quota-available-bytes on a resource /A/UploadDirectory and the quota > is actually enforced on the parent, that you would essentially walk up > the tree until you found an appropriate "mount point" based quota > requirement. If this is true, the quota-used-bytes should do the same > thing. Meaning, quota-used-bytes on /A/UploadDirectory would be the > same as quota-used-bytes /A if /A/UploadDirectory did not contain a > more specific quota rule. > > This is also an efficiency win for implementors. If an implementation > has to support quota-used-bytes on an arbitrary URL, it is impractical > to think that quota-used-bytes could be incrementally adjusted and > would necessarily need to be calculated on-the-fly, which does not > scale well for most implementations. > > How NFSv4 handles this situation? > > > Also, under the "Notes" section, "What clients should expect" seems to > have a sentence which is not grammatically correct. > "This allows the space used by /~milele/public/ to be as > large as the quota on /~milele/ allows (depending on the other > contents of /~milele/) even if the quota on /~milele/ is changed." > > Regards, > > Chris. > On Nov 14, 2003, at 2:27 AM, Stefan Eissing wrote: > >> >> Brian, >> >> I put my mind into blank slate mode and read the draft 2 for the >> first time. >> >> I think it is a big improvment from where we started from. One item I >> found >> confusing though and that is the example for DAV:quota-assigned-bytes >> (and the mental model behind the example). >> >> The draft seems to say that /A and /A/B have separate >> DAV:quota-assigned-bytes >> properties, however they are in the same "set of collections" when >> the value >> of DAV:quota-available-bytes/DAV:quota-used-bytes is computed. >> >> (See definition of "set" in the explanation to DAV:quota-used-bytes - >> seems to >> be a copy from the NFS spec.) >> >> In NFS-Quota, the model seems to be simple: each quota applies to a >> set >> of collections/files and each member of this set would report the same >> quota properties. >> >> In WebDAV-quota (draft-2): there is a separate quota for each >> collection >> (e.g. the assigned-bytes), but available-/used-bytes are the same for >> resources in the same set. >> >> Two Problems come to my mind now: >> 1) If a collection of the "set" has the DAV:quota-assigned-bytes not >> explicitly set, what value would it report? Say for /A/C, /A/B/D and >> /E (all in the same set)? >> >> 2) If a client wants to increase DAV:quota-available-bytes in a >> certain >> collection, it has to increase the DAV:quota-assigned-bytes. But in >> your example: increasing assigned-bytes on /A/B will not have any >> effect on the DAV:quota-available-bytes. What is a generic client >> supposed >> to do then? >> >> Best Regards, Stefan >> >> Am 13.11.2003 um 22:06 schrieb Brian Korver: >> >>> >>> On Thursday, November 13, 2003, at 01:14 PM, Julian Reschke wrote: >>>> Brian, >>>> >>>> when I re-raised these issues, I *did* read the current draft. So I >>>> think it's up to you to go back to the mailing list discussion and >>>> explain why the concerns raised by Stefan and myself aren't valid. >>>> >>>> Julian >>> >>> Julian, >>> >>> I'm planning to do so in today's meeting, but to restate for the >>> mailing list, >>> Stefan pointed out that if we used quota-limit, then quota-limit >>> would not be >>> a fixed value (which is the reason we defined things in terms of >>> quota-limit >>> to begin with). Thus, instead of quota-limit, the new draft uses >>> NFS's >>> quota-available. This has the semantics that it isn't fixed. >>> Problem solved. >>> Note, quota-available is consistent with the rest of the the quota >>> definitions >>> we pulled from NFS, so it's conceptually attractive too. >>> >>> I still don't know what you find confusing, so I can't comment on >>> that yet. >>> >>> -brian >>> briank@xythos.com >>
Received on Friday, 12 December 2003 04:34:20 UTC