From: Eric Sandeen <sandeen@sandeen.net> To: Zorro Lang <zlang@redhat.com>, Eryu Guan <eguan@redhat.com> Cc: fstests@vger.kernel.org, xfs@oss.sgi.com, sandeen@redhat.com Subject: Re: [PATCH] xfs/133 134 262: limit xfs_quota report to report on specific project quota id Date: Fri, 1 Apr 2016 12:24:40 -0500 [thread overview] Message-ID: <56FEAED8.2050108@sandeen.net> (raw) In-Reply-To: <20160401072856.GA3329@dhcp12-237.nay.redhat.com> On 4/1/16 2:28 AM, Zorro Lang wrote: > On Fri, Apr 01, 2016 at 03:00:50PM +0800, Eryu Guan wrote: >> With GETNEXTQUOTA support, xfs_quota -c "report" now outputs more quota >> info than before, and this breaks xfs/133 xfs/134 and xfs/262, e.g. >> xfs/133 fails as >> >> Filesystem Blocks Quota Limit Warn/Time Mounted on >> SCRATCH_DEV 0 102400 204800 00 [--------] SCRATCH_MNT >> === report command output === >> +(null) 0 0 0 00 [--------] >> 123456-project 0 102400 204800 00 [--------] >> >> Fix it by limiting xfs_quota to report on specific project quota number >> using -L & -U option, so only the project quota being tested is >> reported. >> >> Signed-off-by: Eryu Guan <eguan@redhat.com> >> --- >> >> I'm not sure if kernel should be fixed, but limiting the quota report on >> project number being tested seems something worth doing to me anyway. It avoids >> breakage of future changes of quota report output. > > Hi, > > FYI: > About "+(null) 0 0 0 00 [--------]"problem, it has been talked in: > http://thread.gmane.org/gmane.comp.file-systems.fstests/1852/focus=1968 > > I think: > 1) If we consider that this's a bug, the original test cases can > be the reproducer of this bug, so we shouldn't change the cases. > > 2) If we think print "(null) 0 0 0 00 [--------]" is right(or not > wrong), then this patch is good. yes, I'm sorry I didn't take care of this sooner. I don't think there's value in printing the "(null)" line; I think maybe my suggestion from that old thread might be best: > We could explicitly look up id 0 and not show it if it's not in the > projects file. Or now that I think about it - projid 0 is the default project quota, right? Assuming that's correct, perhaps we should conditionally print the line, changing "(null)" to "default", printing it only if a default quota is set (i.e. not all zeros). -Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Sandeen <sandeen@sandeen.net> To: Zorro Lang <zlang@redhat.com>, Eryu Guan <eguan@redhat.com> Cc: sandeen@redhat.com, fstests@vger.kernel.org, xfs@oss.sgi.com Subject: Re: [PATCH] xfs/133 134 262: limit xfs_quota report to report on specific project quota id Date: Fri, 1 Apr 2016 12:24:40 -0500 [thread overview] Message-ID: <56FEAED8.2050108@sandeen.net> (raw) In-Reply-To: <20160401072856.GA3329@dhcp12-237.nay.redhat.com> On 4/1/16 2:28 AM, Zorro Lang wrote: > On Fri, Apr 01, 2016 at 03:00:50PM +0800, Eryu Guan wrote: >> With GETNEXTQUOTA support, xfs_quota -c "report" now outputs more quota >> info than before, and this breaks xfs/133 xfs/134 and xfs/262, e.g. >> xfs/133 fails as >> >> Filesystem Blocks Quota Limit Warn/Time Mounted on >> SCRATCH_DEV 0 102400 204800 00 [--------] SCRATCH_MNT >> === report command output === >> +(null) 0 0 0 00 [--------] >> 123456-project 0 102400 204800 00 [--------] >> >> Fix it by limiting xfs_quota to report on specific project quota number >> using -L & -U option, so only the project quota being tested is >> reported. >> >> Signed-off-by: Eryu Guan <eguan@redhat.com> >> --- >> >> I'm not sure if kernel should be fixed, but limiting the quota report on >> project number being tested seems something worth doing to me anyway. It avoids >> breakage of future changes of quota report output. > > Hi, > > FYI: > About "+(null) 0 0 0 00 [--------]"problem, it has been talked in: > http://thread.gmane.org/gmane.comp.file-systems.fstests/1852/focus=1968 > > I think: > 1) If we consider that this's a bug, the original test cases can > be the reproducer of this bug, so we shouldn't change the cases. > > 2) If we think print "(null) 0 0 0 00 [--------]" is right(or not > wrong), then this patch is good. yes, I'm sorry I didn't take care of this sooner. I don't think there's value in printing the "(null)" line; I think maybe my suggestion from that old thread might be best: > We could explicitly look up id 0 and not show it if it's not in the > projects file. Or now that I think about it - projid 0 is the default project quota, right? Assuming that's correct, perhaps we should conditionally print the line, changing "(null)" to "default", printing it only if a default quota is set (i.e. not all zeros). -Eric _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-04-01 17:24 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-04-01 7:00 [PATCH] xfs/133 134 262: limit xfs_quota report to report on specific project quota id Eryu Guan 2016-04-01 7:00 ` Eryu Guan 2016-04-01 7:28 ` Zorro Lang 2016-04-01 7:28 ` Zorro Lang 2016-04-01 17:24 ` Eric Sandeen [this message] 2016-04-01 17:24 ` Eric Sandeen 2016-04-01 21:50 ` Dave Chinner 2016-04-01 21:50 ` Dave Chinner 2016-05-11 8:26 ` Zorro Lang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=56FEAED8.2050108@sandeen.net \ --to=sandeen@sandeen.net \ --cc=eguan@redhat.com \ --cc=fstests@vger.kernel.org \ --cc=sandeen@redhat.com \ --cc=xfs@oss.sgi.com \ --cc=zlang@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.