On Wed, Nov 26, 2014 at 03:26:26PM -0600, Eric Sandeen wrote:
> On 11/26/14 3:21 PM, Dave Chinner wrote:
> > 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....
>
> if I ask for something that doesn't exist by name, it tells me:
>
> # xfs_quota -x -c 'quota -pv project4' /mnt/test
> xfs_quota: cannot find project project4
It can't convert it to a prid because it's not in the /etc/projects
file. Project quotas are a little bit special in this way.
> or if I ask by prid, I get nothing with or without -v :(
>
> # xfs_quota -x -c 'quota -pv 4' /mnt/test
> #
Ah, I missed the XFS_IS_DQUOT_UNINITIALIZED() check at the syscall
entry point. It checks for everything being zero and returns -ENOENT
if it's an empty dquot. Too many bloody layers of validation....
> > 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....
>
> That's all well and good, but with -v it is able to tell me what
> the set limits are, and that I have no blocks allocated within those limits.
>
> So the information we might expect seems available; it's just not
> shown, because the code short-circuits it w/o -v.
>
> Or am I missing something ...
Nope, I'm confusing different reporting command behaviour....
Cheers,
Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
