[PATCH] xfs_quota: print quota id number if the name can't be found
Eric Sandeen
sandeen at redhat.com
Wed Apr 6 13:34:22 CDT 2016
On 4/6/16 12:39 PM, Zorro Lang wrote:
> When use GETNEXTQUOTA ioctl to report project quota, it always
> report an unexpected quota:
>
> (null) 0 0 0 00 [--------]
>
> The ID 0 store the default quota, even if no one set default quota,
> it still have quota accounting, but not enforced. So GETNEXTQUOTA
> can find and report this undefined quota.
>
> From this problem, I thought if others' quota name miss, (null) will
> be printed too. e.g.
>
> # xfs_quota -xc "limit -u bsoft=300m bhard=400m test" $mnt
> # xfs_quota -xc "report -u" $mnt
> User ID Used Soft Hard Warn/Grace
> ---------- --------------------------------------------------
> root 0 0 0 00 [--------]
> test 0 307200 409600 00 [--------]
> # userdel -r test
> # xfs_quota -xc "report -u" $mnt
> User ID Used Soft Hard Warn/Grace
> ---------- --------------------------------------------------
> root 0 0 0 00 [--------]
> (null) 0 307200 409600 00 [--------]
>
> So this problem same with above id 0's problem. For deal with this,
> this patch will print id number if the name can't be found.
>
> But if use old GETQUOTA ioctl, it won't print project id 0 quota
> information(if it's not defined). That's different with GETNEXTQUOTA.
> For keep consistent, this patch also print project id 0 when use old
> GETQUOTA.
>
> Signed-off-by: Zorro Lang <zlang at redhat.com>
Thanks, I think this makes sense; so this solves 2 problems.
1) always print the id # if there is no name mapping during quota report, and
2) always print default project quota information, even if no PRID 0 in in the projects map.
UID & GID always (?) have an ID 0 defined (if the system has no root user or group,
something is very odd, but it is normal to have no PRID 0 defined)
other comments below.
> ---
>
> Hi,
>
> This's a problem from GETNEXTQUOTA feature. The original disscussion
> is as below:
>
> http://thread.gmane.org/gmane.comp.file-systems.fstests/1852/focus=1968
>
> Then Eryu send a patch to xfstests, try to fix the test failure bring
> by this bug. The disscussion is as below:
>
> http://oss.sgi.com/archives/xfs/2016-04/msg00002.html
>
> Finally we decided to fix this problem in xfsprogs. After talked with
> Eric Sandeen, I wrote this patch. At first, Eric thought we shouldn't
> print project id 0 quota information, if no one set limit for it.
>
> Then he change his mind to always print "root" as project id 0's name,
> if no one define a name for it. But there's another problem, if we
> print "root" for project id 0, but we can't run:
>
> xfs_quota -xc "limit -p xxx xxx root" $mnt
>
> Because the "root" is a fake name. Then I suggest to print id number,
> if the name can't be found. This method not only used for project id
> 0, it used for all user/group/project IDs which no name defined.
>
> So this patch should be the V3 patch. We can't sure which one is the
> best idea. If anyone have better idea, please tell me.
>
> Thanks,
> Zorro
>
> quota/report.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/quota/report.c b/quota/report.c
> index 48a3f29..557d667 100644
> --- a/quota/report.c
> +++ b/quota/report.c
> @@ -389,7 +389,10 @@ report_mount(
> name = p->pr_name;
> }
> }
> - fprintf(fp, "%-10s", name);
Could use a comment:
+ /* If no name is found, print the id # instead of (null) */
> + if (name != NULL)
> + fprintf(fp, "%-10s", name);
> + else
> + fprintf(fp, "#%-10u", d.d_id);
> }
>
> if (form & XFS_BLOCK_QUOTA) {
> @@ -571,6 +574,12 @@ report_project_mount(
> id = oid + 1;
> }
> } else {
Comment:
+ /* Print default project quota even if PRID 0 isn't defined */
> + if (!getprprid(0)) {
> + report_mount(fp, 0, "#0", NULL, form, XFS_PROJ_QUOTA,
If you pass in NULL instead of "#0" does report_mount do the right thing?
If so, better to not hard-code "#0" here.
-Eric
> + mount, flags);
> + flags |= NO_HEADER_FLAG;
> + }
> +
> setprent();
> while ((p = getprent()) != NULL) {
> if (report_mount(fp, p->pr_prid, p->pr_name, NULL,
>
More information about the xfs
mailing list