Re: fs-independent quotas

[Adam Hamsik <haaaad%gmail.com@localhost>]

Hi,

On Nov,Friday 11 2011, at 1:59 PM, David Holland wrote:

> On Sat, Oct 29, 2011 at 05:14:30PM +0000, David Holland wrote:
>> The new discovery that struct ufs_quota_entry is meant to be
>> fs-independent changes the complexion of things quite a bit.
> 
> ok, so my poor choice of wording and/or bikeshedding burnout has
> caused this thread to run down, except for the terminology part.
> 
> Here's what I'm planning to do:
> 
>> ISTM that there are four more or less separable issues now:
>> 
>>   1. Fix the name of struct ufs_quota_entry and any related things to
>>      make it clear that they're fs-independent. This is not optional.
>> 
>>   2. Clean up the userlevel quota tools and libquota along the lines
>>      I previously proposed, giving libquota a clear API and
>>      centralizing all the legacy userlevel quota code.
> 
> I'm going to proceed on these, since (1) is clearly necessary and
> there was not significant opposition to the parts of the previous
> proposal that constitute (2).

Stating that there was no opposition when current maintainer said 
that he doesn't think that your change is needed seems to be wrong to me.


> 
> One semi-open question remains: whether the future published/supported
> userlevel libquota API should involve #include <quota/quota.h> or
> #include <quota.h>. I'm going to go with the latter (no subdir), as
> previously proposed, unless someone has a strong opinion and expresses
> it fairly soon.
> 
> I am also, as one of the people concerned with the design of the VFS
> interface, going to move the xmlrpc processing code out of the
> filesystems and institute a relatively simple API for VOP_QUOTACTL.
> I'll post what I'm going to do in this regard when I have a design (or
> patches) ready.
> 
> Since in the worst case extending the VOP_QUOTACTL interface requires
> only a kernel version bump, I think it's pretty clear that this
> interface should be kept simple for now. When and if new and
> semantically expanded quota functionality should appear in some
> filesystem, which is not likely to be anytime soon if ever, we can
> adjust VOP_QUOTACTL and swallow a kernel version bump then.
> 
>>   3. Abolish the proplib-based transport encoding. Since it turns out
>>      that the use of proplib for quotactl(2) is only to encode struct
>>      ufs_quota_entry for transport across the user/kernel boundary,
>>      converting it back on the other side, it seems to me that it's
>>      a completely pointless complication and a poor use of proplib.
>>      It's also messy, even compared to other proplib usage elsewhere.
>>      (Regarding claims of easier/better compatibility, see below.)
>> 
>>   4. Abolish the xmlrpc-type user interface of quotactl(8) in favor
>>      of something else saner and easier to work with.
> 
> I'm going to ask core to decide these two. If the decision is to
> proceed on (4) I'm planning to move the xmlrpc processing code into
> quotactl(8) and keep it around for a while in case anyone has backup
> dumps in that format that they need to convert. ("A while" I think
> means a few weeks, not a few releases. If this interface is going to
> be removed, I don't think it should be present in netbsd-6.)

Why is introducing new form of interface better than using standard \
one even if you do not like it ?


> 
>> - We still need suggstions for better terminology than "quota classes"
>> and "quota types".
> 
> This part of the discussion I'm going to try to get started again.
> 
> -- 
> David A. Holland
> dholland%netbsd.org@localhost

Regards

Adam.