Re: [PATCH 0/4] quota: add new quotactl Q_XGETQUOTA2

[Eric Sandeen <sandeen@sandeen.net>]

On 1/18/16 9:40 AM, Jan Kara wrote:
> On Mon 18-01-16 09:18:16, Eric Sandeen wrote:
>> On 1/18/16 4:33 AM, Jan Kara wrote:
>>> On Fri 15-01-16 11:31:00, Eric Sandeen wrote:
>>
>> ...
>>
>>>> For a purpose-built interface of "find the next ID" that wouldn't require any
>>>> structure or interface changes...
>>>>
>>>> We could name it Q_GETNEXTQUOTA / Q_XGETNEXTQUOTA to make it explicit about
>>>> the purpose, and document that return behavior.  Done & done.  ;)
>>>>
>>>> A new grand unified extensible quota call sounds like a great idea, I just
>>>> hate to gate this work on designing a brand-new interface.
>>>
>>> OK, ok. I like Dave's proposal for quotactl2(). So let's leave the unification
>>> for later and implent Q_GETNEXTQUOTA and Q_XGETNEXTQUOTA with the
>>> functionality of your original Q_XGETQUOTA2. Having separate call to get
>>> next ID would save us one new quotactl but OTOH we would need two syscalls
>>> (and quota structure lookups) to report one structure and there are
>>> potentially *lots* of them.
>>
>> Ok, I can re-do it with the new Q_[X]GETNEXTQUOTA names, I've already done
>> the non-xfs one as well, just starting testing on that.
>>
>> With or without the flags argument?
> 
> Without. For further extensibility I'd really go for the unified API in the
> end.

Thanks.  I'll get new patches out in a bit, putting some polish on them and
the userspace, and seeing about a regression test as well.

Realized I need to think semi-carefully about what we do for IDs found on
disk but not in the user database; today I think extN will show everything;
XFS only shows IDs in the DB, unless an ID range is specified - probably
need to keep all behavior the same, without some explicit commandline switches
to do differently.

Thanks,
-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs