On Thu, Apr 07, 2016 at 10:48:34PM +0800, 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@xxxxxxxxxx> OK, so with this applied xfs/133 and xfs/134 both now fail with this extra output: +#0 0 0 0 00 [--------] Can you send patches for these tests to filter out these lines so that the tests pass again for both old and new xfsprogs? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
