On Tue 06-09-11 10:50:09, Christoph Hellwig wrote: > On Tue, Sep 06, 2011 at 04:43:34PM +0200, Jan Kara wrote: > > All I had (well, except a tool which verifies sanity of quotactl syscall > > but that's out of scope for xfstests I'd say) is already integrated into > > xfstests. > > > > We have test 219 which tests whether quota measures something sane. > > Test 230 tries to exceed various quota limits and checks that it fails > > roughly at the right moment. > > Tests 231 and 232 check that if we stress the filesystem (fsx, fsstress), > > the resulting quota usage is indeed what we get when we sum up the usage > > using quotacheck (which is worthless for XFS but for ext? filesystems this > > is really useful). > > Test 233 checks running fsstress with quotas set low so that we often hit > > EDQUOT. We also verify that usage matches what quotacheck gets. > > Finally test 234 stresses operations on top of quota files by adding and > > removing quota structures by setquota from several processes. > > > > What other tests would you like to have? > > In XFS we have a few counters for evens in the quota code, and I noticed > that we're barely ever hitting reclaim of dquots due to memory pressure, > not do we ever see racing quota lookups. So one thing I'd like to to > is all kinds of heavy fs stressing with quotas enabled. One option is > to simply run all of xfstests with quotas enabled, which I already did, > but I'm still not hitting any of these above. That's a good plan. To verify reclaim behavior for VFS quotas, we could pull quota structures in memory using GETQUOTA and then apply memory pressure to have them reclaimed. If we also want to combine this with updates to those structures because of allocations it gets more complicated. We'd have to do IO for several different users in sequence under memory pressure so that all inodes of one user get pushed out of memory and quota structure is thus freed for reclaim as well. As for racing lookups / other quota operations - these are not that much interesting for VFS quotas because a) once quota structure is created, it's position on disk is fixed b) any operation on quota file that does more than update accounting information in a structure is protected by per quota-file mutex. c) in memory operations with quota structures are protected by one global spinlock So there is no paralelism to worry about. But sure it's good to verify this by pushing the filesystem as hard as possible :-). Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
