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

On Sep 7, 2004, at 11:04 PM, Julian Reschke wrote:
> Brian Korver wrote:
>
>> 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.
>
> 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).
>
>> 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.
>
> 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.

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


> 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.

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


>
> Best regards, Julian
>
>
> -- 
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>
-brian
briank@xythos.com

Received on Wednesday, 8 September 2004 16:28:52 UTC