On 2/19/16 12:33 PM, Jan Kara wrote:
> On Fri 19-02-16 11:31:58, Eric Sandeen wrote:
>>
>>
>> On 2/4/16 8:28 AM, Jan Kara wrote:
>>> Add infrastructure for supporting get_nextdqblk() callback for VFS
>>> quotas. Translate the operation into a callback to appropriate
>>> filesystem and consequently to quota format callback.
>>>
>>> Signed-off-by: Jan Kara <jack@xxxxxxx>
>>> ---
>>> fs/ext4/super.c | 1 +
>>> fs/quota/dquot.c | 39 +++++++++++++++++++++++++++++++++++++++
>>> fs/reiserfs/super.c | 1 +
>>> include/linux/quota.h | 3 +++
>>> include/linux/quotaops.h | 3 +++
>>> 5 files changed, 47 insertions(+)
>>>
>>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>>> index f1b56ff01208..51649f442bf6 100644
>>> --- a/fs/ext4/super.c
>>> +++ b/fs/ext4/super.c
>>> @@ -1100,6 +1100,7 @@ static const struct dquot_operations ext4_quota_operations = {
>>> .write_info = ext4_write_info,
>>> .alloc_dquot = dquot_alloc,
>>> .destroy_dquot = dquot_destroy,
>>> + .get_next_id = dquot_get_next_id,
>>> };
>>
>> Hi Jan, doesn't this also need to set:
>>
>>
>> + .get_nextdqblk = dquot_get_next_dqblk,
>>
>> in ext4_qctl_sysfile_operations?
>
> Indeed, thanks for catching this. Patch added (with your authorship and
> sign-off) into my tree and this time I've properly tested Q_GETNEXTQUOTA
> for ext4 with quota in hidden inodes indeed works (previously I've tested
> only visible quota files).
Thanks Jan, I wasn't quite sure what it should be doing, but this seemed
right. ;) Sorry for not sending a proper patch.
So, when you tested visible quota files, I assume it was just falling
back to the non-next variants of the quotactl, right? We should not
be hooking up the call for the visible quota files, right?
FWIW, there is a test in [x]fstests now for the [X]GETNEXT calls, it's
generic/244
Thanks!
-Eric
> Honza
>
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
