Re: [PATCH v2] xfs: return default quota limits for IDs without a dquot

[Jan Kara <jack@suse.cz>]

Hello!

On Tue 17-03-26 09:31:59, Theodore Tso wrote:
> On Tue, Mar 17, 2026 at 01:19:23PM +0100, Jan Kara wrote:
> > On Tue 17-03-26 14:59:47, Ravi Singh wrote:
> > > When an ID has no dquot on disk, Q_XGETQUOTA returns -ENOENT even
> > > though default quota limits are configured and enforced against that
> > > ID.  This means unprivileged users who have never used any resources
> > > cannot see the limits that apply to them.
> > > 
> > > When xfs_qm_dqget() returns -ENOENT for a non-zero ID, return a
> > > zero-usage response with the default limits filled in from
> > > m_quotainfo rather than propagating the error.  This is consistent
> > > with the enforcement behavior in xfs_qm_adjust_dqlimits(), which
> > > pushes the same default limits into a dquot when it is first
> > > allocated.
> > > 
> > > Signed-off-by: Ravi Singh <ravising@redhat.com>
> > 
> > So XFS guys should also review this but from quota POV this looks like a
> > right fix to me. So feel free to add:
> > 
> > Reviewed-by: Jan Kara <jack@suse.cz>
> 
> This was discussed at last week's ext4 conference call, and we
> wondered whether we might be better off adding a new
> Q_XGETDEFAULTQUOTA or some such which returned the default quota.
> This would that the quota userspace utilities would have to be
> changed, but it would also mean that userspace could distinguish
> between whether the quota limit was due to a default value being used,
> or because the user had an actual quota value set.

First thing to note is that the notion of "default limit" is specific to
XFS. Other filesystems using quota don't have any default limits. I guess
most people here know this but I'm spelling it out so that we are all on
the same page.

> It also means that in the future, if we wanted to change where the
> default quota was stored, it would be possible to do that instead of
> overloading the quota value for uid/gid 0.
> 
> We also speculated that perhaps there might be cases where if some
> process might be running without CAP_SYS_ADMIN, there might be a
> reason that quota for uid=0 might actually make sense, and so perhaps
> some future file system format change might want to decouple where the
> default quota was stored.

Right. That's why I didn't like the v1 version of the patch. But v2 version
hides the XFS specific behavior of default limits inside XFS function for
fetching quotas so that is fully transparent. If XFS decides to change its
quota format to support limits for root, it can also change this code
fetching and filling in default limits for the user. So until XFS decides
to change the format, current solution looks fine to me, once it decides to
change it, it is easy to change this code as well. But obviously this is
fully XFS developers' area of code so they can do whatever they wish :)

The only improvement I can see is if we explicitely wanted to expose the
XFS default limits in some generic way for userspace tools to show. But
then I'd think we don't really need new quotactl, we could just put this
into the result of existing Q_XGETQSTATV quotactl.

Overall I don't have a strong opinion on this and consider these questions
mostly specific to XFS so XFS guys should decide what they want...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR