[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fs-independent quotas
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
Main Index |
Thread Index |