On 1/11/16 7:26 AM, Jan Kara wrote:
> On Fri 08-01-16 23:26:00, Christoph Hellwig wrote:
>> On Fri, Jan 08, 2016 at 10:56:12AM -0600, Eric Sandeen wrote:
>>> This adds a new quotactl, Q_XGETQUOTA2.
>>>
>>> Q_XGETQUOTA2 is exactly like Q_XGETQUOTA, except that it will
>>> return quota information for the id equal to or greater than
>>> the id requested. In other words, if the specified id has
>>> no quota, the command will return quota information for the
>>> next higher id which does have a quota set. If no higher id
>>> has an active quota, -ESRCH is returned.
>>
>> Please add a flags argument to Q_XGETQUOTA2, and then make the
>> new behavior the first flag. Keep Q_XGETQUOTA behavior for the
>> flag-less case. That way we get future etensibility for free.
>
> So this is what I wanted to suggest at first as well. What I somewhat
> dislike is that 'addr' must now point to something like:
>
> struct getquota_args {
> __u64 flags;
> struct fs_disk_quota ret;
> };
Ok...
> which is not as nice as passing pointer to fs_disk_quota directly. But
> probably still OK. So I agree with the flags idea.
I understand that flags are for future-proofing, for possibly-not-yet-imagined
scenarios, but on the other hand, I wonder how many different flavors of
"get me a disk quota" we really expect to have?
> Another issue is that OCFS2 and ext4 with quota in hidden inodes would need
> call with these capabilities as well (they have the same problem as xfs).
> For reporting VFS quota we use bytes for space (since some filesystems need
> it) and we don't need RT fields (easy so zero-fill) and warning fields
> (there zeros may be confusing). So we would need something like struct
> qc_dqblk (currently only internal) extended with ID and maybe flags field
> XFS is using to return quota type which can contain all the information and
> tell which info is actually valid as return structure.
Hohum, yeah - I forgot that ext4 has (can have?) a hidden quota inode.
And I didn't know about OCFS2.
And TBH I did the xfs-specific one because it was trivial to extend, with the
id already in the returned quota struct.
So ok, it sounds like this needs a more significant overhaul at the vfs
quota level...
-Eric
>
> Honza
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
