Subject: Quota: another DAV:quota-assigned-bytes question

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Sep 2004 11:25:57 +0200

OK,

here's another question about DAV:quota-assigned-bytes...:

Let's assume a quota system that works as the one in Unix and/or Windows 
NT, that is

- quota can be enabled/disabled per physical file system,
- quota is counted per user across all files on that file system.

Consider a server that has a lot of users for who quotas are set up. 
Most of these users will not have the permission to change their quota 
on their own.

On the other hand, users with admin privileges are authorized to change 
quota for other users, however there doesn't seem to be a way for them 
to use DAV:quota-assigned-bytes for it (as this property will vary by 
authenticated user, not the request URI).

To summarize, the property as currently described seems to work only for 
those cases where quota is maintained by folder, not by user and doesn't 
seem to usable for other systems.

Thus, the whole concept of "authorable" quota should be either removed 
from the spec, or it needs to be rewritten in a way so that it works for 
other scenarios as well. (my preference being to leave it out unless 
there are volunteers who want to work on this issue).

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Brian Korver <[email-masked]>
Date: Fri, 3 Sep 2004 09:21:48 -0700

Anyone who is going to support this use case should speak up
because if no one wants to support your proposed use case then
the issue is moot.

-brian
[email-masked]

On Sep 3, 2004, at 2:25 AM, Julian Reschke wrote:
> Let's assume a quota system that works as the one in Unix and/or 
> Windows NT, that is
>
> On the other hand, users with admin privileges are authorized to 
> change quota for other users, however there doesn't seem to be a way 
> for them to use DAV:quota-assigned-bytes for it (as this property will 
> vary by authenticated user, not the request URI).
>
> To summarize, the property as currently described seems to work only 
> for those cases where quota is maintained by folder, not by user and 
> doesn't seem to usable for other systems.
>
> from the spec, or it needs to be rewritten in a way so that it works 
> for other scenarios as well. (my preference being to leave it out 
> unless there are volunteers who want to work on this issue).
>
> Best regards, Julian
>
> --

---

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Sep 2004 18:39:25 +0200

> because if no one wants to support your proposed use case then

So you're saying that the fact that the protocol as specified is 
incompatible with both the NTFS and Unix quota model is moot?

As far as I can tell, the spec as currently published is optimized for 
one very specific implementation. That's fine, unless people want to 
make it *the* quota protocol with backing of the WebDAV working group.

Please either simplify the protocol in a way so that other 
implementations become possible (moving too specific features into 
private extensions), or publish what you have as Informational RFC 
describing what one specific system is supporting today.

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 3 Sep 2004 17:31:29 -0400

I'm inclined to agree with Julian.  A working group standard 
should be compatible with common industry models, unless those
models are inherently incompatible.  So an informational RFC
seems more appropriate unless that compatibility is achieved.

Cheers,
Geoff

---

From: Brian Korver <[email-masked]>
Date: Fri, 3 Sep 2004 15:06:51 -0700

Geoff,

I agree.  And I agree with Julian that the "quota" model
in the spec associates quota with resources, not users,
which makes it inherently incompatible with the Unix model.
But I don't think anyone could reasonably argue that the
spec should be changed to associate quota with users.
That would be unDAVlike, unNFSlike, etc.  Of course, someone
could unreasonably argue that position....  ;-)

-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Sep 2004 09:58:24 +0200

> spec should be changed to associate quota with users.

Well, we do. Many quota systems work like that; and if this is supposed 
to become the Quota spec supported by the IETF WebDAV mailing list, it 
should be compatible with these systems.

Or on the other hand, removing this part of the spec resolves *that* 
issue, and as far as I can tell, only one single vendor is supporting it 
anyway. So why not make it a private extension?

> could unreasonably argue that position....  ;-)

I don't get that point. Could you please explain...?

Best regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Sat, 4 Sep 2004 10:44:25 +0200

> seems more appropriate unless that compatibility is achieved.

I fully agree.

//Stefan

---

From: Brian Korver <[email-masked]>
Date: Tue, 7 Sep 2004 14:42:28 -0700

On Sep 4, 2004, at 12:58 AM, Julian Reschke wrote:
> Well, we do. Many quota systems work like that; and if this is 
> supposed to become the Quota spec supported by the IETF WebDAV mailing 
> list, it should be compatible with these systems.
>
> issue, and as far as I can tell, only one single vendor is supporting 
> it anyway. So why not make it a private extension?
>

We agreed to follow the NFS model and in fact pulled the
text essentially unchanged from the NFS RFC.

-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Sep 2004 23:54:55 +0200

Brian Korver wrote:

 > ...

So does NFS marshall disk limits trhough quota properties? No. Does NFS 
make quuto authorable? No.

See?

Julian

---

From: Brian Korver <[email-masked]>
Date: Tue, 7 Sep 2004 15:29:45 -0700

I was responding to an earlier suggestion that
the model be scrapped in favor of one you proposed
not doing.  We agreed to the quota-by-resource model,
no one has proposed doing any other, so the issue
is resolved.

But, to answer your questions: Yes, the NFS spec does
seem to allow disk limits to me marshalled through
the quota properties and certainly doesn't prohibit
this ("the server is at liberty to choose").  NFS
chooses to define these properties as read-only.

-brian
[email-masked]

On Sep 7, 2004, at 2:54 PM, Julian Reschke wrote:
> So does NFS marshall disk limits trhough quota properties? No. Does 
> NFS make quuto authorable? No.
>
> See?
>
> Julian
>
>
> --

---

From: Jim Luther <[email-masked]>
Date: Tue, 7 Sep 2004 15:44:23 -0700

After reading all of these arguments, my input is "It's too bad the  
term "quota" was chosen in the first place."

The Mac OS X WebDAV file system does not support Unix-like file system  
quotas.

The Mac OS X WebDAV file system uses the old quota properties* to fill  
in the f_blocks (total data blocks in filesystem) and f_bfree (free  
blocks in filesystem) fields returned by statfs(2).  In the Mac OS X  
user interface, those fields become the Capacity, Available, and Used  
numbers displayed in volume information dialogs (as in "Capacity:  
100MB" "Available: 49.2 MB" "Used: 50.8 MB on disk").

On Apple's .Mac iDisk WebDAV server, if a client PUT request would  
cause a user's purchased space to be exceeded, the server returns 507  
Insufficient Storage and the WebDAV file system translates that to  
ENOSPC "No space left on device" (not to EDQUOT "Disc quota exceeded").

For our purposes, the quota properties are considered live properties  
which cannot be changed by the file system client.

So, we're using the old quota properties in a way that compatible with  
a common industry model... it just isn't the model many on this list  
are associating with the term "quota".

- Jim

* DAV: quota and DAV: quotaused as mentioned at  
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/ 
0209.html>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Sep 2004 08:04:15 +0200

> no one has proposed doing any other, so the issue

I can't remember that anybody agreed on that (pointer, please?). The 
only p.o.v. that makes sense to me is that the Quota protocol only 
discusses marshalling, but not the Quota system itself. Thus it should 
work both with user/group-based and resource-based quota (and other 
systems that may exist).

> chooses to define these properties as read-only.

RFC3530, section 5.10:

          Note that there may be a number of distinct but overlapping
          sets of files or directories for which a quota_used value is
          maintained (e.g., "all files with a given owner", "all files
          with a given group owner", etc.).

          The server is at liberty to choose any of those sets but should
          do so in a repeatable way.  The rule may be configured per-
          filesystem or may be "choose the set with the smallest quota".

So no, this doesn't apply to disk limits - disk limits are *not* quotas. 
RFC3530 discusses disk limits in section 5.6:

    space_free          43   uint64         READ     Free disk space in
                                                     bytes on the
                                                     filesystem
                                                     containing this
                                                     object - this should
                                                     be the smallest
                                                     relevant limit.

    space_total         44   uint64         READ     Total disk space in
                                                     bytes on the
                                                     filesystem
                                                     containing this
                                                     object.

    space_used          45   uint64         READ     Number of filesystem
                                                     bytes allocated to
                                                     this object.

Also note that RFC3530 distinguishes error conditions for both (section 12):

    NFS4ERR_DQUOT         Resource (quota) hard limit exceeded. The
                          user's resource limit on the server has been
                          exceeded.

and

    NFS4ERR_NOSPC         No space left on device. The operation would
                          have caused the server's filesystem to exceed
                          its limit.

So again, lett's just do what NFS does: define properties for quota and 
disk limits, keep the quota definitions such as they are compatible with 
existing quota systems, distinguish error conditions clearly and keep 
things read-only.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 08 Sep 2004 08:23:18 +0200

> are associating with the term "quota".

Jim,

thanks for the information.

I think the best (if not only way) to make progress is to focus what 
parts actually *need* to be standardized.

As far as I can tell, people want their clients to display a 
available/free/used-by-this item indicator in their client. They may or 
may not care whether this is due to disk limits or quota. They also 
expect usable error messages.

I do *not* see anybody asking for

- authorable quota settings (there's only one server implementing that 
right now) and
- there is certainly no demand whatsoever to restrict this to one 
specific system of computing quota.

So let's please focus on what aspects need to be standardized for 
interoperability, and which don't. Remove those that don't, and I'm sure 
we can make quick progress.

Best regards, Julian

---

From: "Eric Sedlar" <[email-masked]>
Date: Wed, 8 Sep 2004 08:01:33 -0700

I agree with Julian on this.  All we want to standardize is the answer to
the question:
if I store some data at the filesystem indicated by this particular URL, how
much data
can I store before getting some kind of out of space error?

--Eric

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 8 Sep 2004 11:22:30 -0400

I agree with Eric and Julian.

Cheers,
Geoff

---

From: Brian Korver <[email-masked]>
Date: Wed, 8 Sep 2004 09:28:16 -0700

> So no, this doesn't apply to disk limits - disk limits are *not* 

The text says otherwise: The server can choose whatever set of
resources it wants to compute quota.  It puts no restrictions
on that.  Period.

>                                                     object - this 
> should
> So again, lett's just do what NFS does: define properties for quota 
> and disk limits, keep the quota definitions such as they are 
> compatible with existing quota systems, distinguish error conditions 
> clearly and keep things read-only.

That all sounds good, but you ascribe properties to NFS that it
doesn't have (ex: compatible with [all] existing quota systems).

Personally I don't have any issue with adding another error code.
I know in practice they'll be treated as semantically equivalent,
so it seems gratuitous, but let's

-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Sep 2004 00:07:32 +0200

> resources it wants to compute quota.  It puts no restrictions

Brian, this is a paragraph from a section that talks about quota and 
nothing else, so of course it talks only about quota.

> doesn't have (ex: compatible with [all] existing quota systems).

Ok. Which one is it incompatible with?

Best regards, Julian

---

From: Brian Korver <[email-masked]>
Date: Wed, 8 Sep 2004 15:17:55 -0700

> nothing else, so of course it talks only about quota.

Precisely, and it states the server can choose how it computes
quota.  Again, not only does the spec place no restrictions on
how the server chooses to compute quota, it explicitly states
there are no restrictions.

> Ok. Which one is it incompatible with?

I thought you said it wasn't compatible with authorable quota
systems....  ;-)

-brian
[email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Thu, 09 Sep 2004 09:41:39 +0200

Brian Korver wrote:
> ..

OK, let's just agree that we disagree. I don't think that any further 
dicussion makes sense.

> I thought you said it wasn't compatible with authorable quota

No, I didn't say that. What I said is that it doesn't *support* it. 
Obviously you can have authorable quota on a system that supports NFS. 
You just can't use NFS (at least not this part of the protocol; maybe 
there's something else) to *do* it.

Julian