On 2/19/16 9:58 AM, Eric Sandeen wrote: > > > On 2/19/16 9:35 AM, Zirong Lang wrote: >> >> >> ----- 原始邮件 ----- >>> 发件人: "Dave Chinner" <david@xxxxxxxxxxxxx> >>> 收件人: "Zorro Lang" <zlang@xxxxxxxxxx> >>> 抄送: fstests@xxxxxxxxxxxxxxx, eguan@xxxxxxxxxx >>> 发送时间: 星期五, 2016年 2 月 19日 上午 9:33:16 >>> 主题: Re: [PATCH] xfs: change return value check to golden image check >>> >>> On Fri, Feb 12, 2016 at 12:37:36AM +0800, Zorro Lang wrote: >>>> xfs/133 and xfs/138 use too much code to do "return value" check, >>>> it's not necessary. For the code can be more readable and clear, >>>> I change "return value" check to golden image check. >>>> >>>> Signed-off-by: Zorro Lang <zlang@xxxxxxxxxx> >>>> --- >>>> tests/xfs/133 | 20 +++++++------------- >>>> tests/xfs/133.out | 7 +++++++ >>>> tests/xfs/138 | 26 ++++++++++++-------------- >>>> tests/xfs/138.out | 12 ++++++++++++ >>>> 4 files changed, 38 insertions(+), 27 deletions(-) >>> >>> This cause a xfs/133 failure like this on my systems: >>> >>> --- tests/xfs/133.out 2016-02-19 10:40:57.043131919 +1100 >>> +++ /home/dave/src/xfstests-dev/results//xfs/xfs/133.out.bad 2016-02-19 >>> 12:24:53.173589432 +1100 >>> @@ -4,5 +4,6 @@ >>> Filesystem Blocks Quota Limit Warn/Time Mounted on >>> SCRATCH_DEV 0 102400 204800 00 [--------] SCRATCH_MNT >>> === report command output === >>> +(null) 0 0 0 00 [--------] > > I need to dig, but this may be a result of GETNEXTQUOTA additions to > xfs_quota. > > We can now find IDs on disk that don't exist in the user database, and > we would not have reported them before. > > Perhaps change the test to report ids not names, to debug it and see > which one it is finding? > > I'm guessing it's ID 0, but I have to think about whether that's correct > to show or not... Ok, with Zorro's help, we see that this is a result of GETNEXTQUOTA. With that in place, "report" shows all active quotas, skipping only if XFS_IS_DQUOT_UNINITIALIZED(). But project ID 0 has 4 inodes accounted for: # xfs_db -c "dquot -p 0" -c print /dev/... ... diskdq.bcount = 0 diskdq.icount = 4 diskdq.itimer = 0 diskdq.btimer = 0 ... We never reported ID 0 before, because it was not in the projects file. But it looks active, so GETNEXTQUOTA finds and returns it now. I'm not actually sure what the best way is to fix this; I was even on the fence about using GETNEXTQUOTA for project quotas at all, because we always have a local file of projects to iterate anyway. We could explicitly look up id 0 and not show it if it's not in the projects file. We could not use GETNEXTQUOTA in the kernel for project quotas. We could skip printing id 0 altogether in xfs_quota We could filter it out in the test ... -Eric -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
