From: Dave Chinner <david@fromorbit.com> To: Eric Sandeen <sandeen@sandeen.net> Cc: Zorro Lang <zlang@redhat.com>, Eryu Guan <eguan@redhat.com>, 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: Sat, 2 Apr 2016 08:50:35 +1100 [thread overview] Message-ID: <20160401215035.GM30721@dastard> (raw) In-Reply-To: <56FEAED8.2050108@sandeen.net> On Fri, Apr 01, 2016 at 12:24:40PM -0500, Eric Sandeen wrote: > > > 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? "default" as in "project quota not enabled on this inode". i.e. if an inode has projid == 0 then it is not tracked by project quotas. > 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). Right, the only thing that the dquot for projid 0 holds is default quota limits. We probably shouldn't ever print it out, except when the default limits are queried or set directly... Cheers, Dave. -- Dave Chinner david@fromorbit.com
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com> To: Eric Sandeen <sandeen@sandeen.net> Cc: sandeen@redhat.com, Zorro Lang <zlang@redhat.com>, Eryu Guan <eguan@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: Sat, 2 Apr 2016 08:50:35 +1100 [thread overview] Message-ID: <20160401215035.GM30721@dastard> (raw) In-Reply-To: <56FEAED8.2050108@sandeen.net> On Fri, Apr 01, 2016 at 12:24:40PM -0500, Eric Sandeen wrote: > > > 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? "default" as in "project quota not enabled on this inode". i.e. if an inode has projid == 0 then it is not tracked by project quotas. > 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). Right, the only thing that the dquot for projid 0 holds is default quota limits. We probably shouldn't ever print it out, except when the default limits are queried or set directly... Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-04-01 21:50 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 2016-04-01 17:24 ` Eric Sandeen 2016-04-01 21:50 ` Dave Chinner [this message] 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=20160401215035.GM30721@dastard \ --to=david@fromorbit.com \ --cc=eguan@redhat.com \ --cc=fstests@vger.kernel.org \ --cc=sandeen@redhat.com \ --cc=sandeen@sandeen.net \ --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.