On Wed, Nov 26, 2014 at 01:26:55PM -0600, Eric Sandeen wrote:
> This seems a bit weird:
>
> # xfs_quota -x -c 'quota -p project1' /mnt/test
> #
>
> Huh, did it work?
>
> # xfs_quota -x -c 'quota -pv project1' /mnt/test
> Disk quotas for Project project1 (1)
> Filesystem Blocks Quota Limit Warn/Time Mounted on
> /dev/sdc2 0 1024000 1228800 00 [--------] /mnt/test
> #
>
> Oh, ok!
>
> I don't know why reporting limits should depend on the verbose flag, but it
> has been that way since 2005 in quota_mount() :
>
> if (!(flags & VERBOSE_FLAG)) {
> count = 0;
> if ((form & XFS_BLOCK_QUOTA) && d.d_bcount)
> count++;
> if ((form & XFS_INODE_QUOTA) && d.d_icount)
> count++;
> if ((form & XFS_RTBLOCK_QUOTA) && d.d_rtbcount)
> count++;
> if (!count)
> return 0;
> }
>
> I'm inclined to change it, but is it OK to change the output of this - might old
> scripts be relying on this (odd) silent behavior? I think it can certainly cause
> confusion (as evidenced by at least one bug I'm looking at ...)
It's done that way because the quota lookup can find dquots that are
completely empty because there are no uid/gid/prid found in the
filesystem, but the dquot is allocated because it's within a block
that has in use dquots in it. I'd guess that if you queried a
non-existent project quota (e.g. prid 2) you'd get the same
result....
i.e. you've got to have inodes or blocks accounted to have a dquot
"created" for the uid/gid/prid in normal conditions, hence dquots
with zero counts are ignored by default as they are effectively
the same as unallocated dquots....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
