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 > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs