Re: [PATCH] xfstests: Improve test 219 to work with all filesystems

[Dave Chinner <david@fromorbit.com>]

On Wed, May 18, 2011 at 10:24:22AM +0200, Jan Kara wrote:
> On Wed 18-05-11 09:13:01, Dave Chinner wrote:
> > On Tue, May 17, 2011 at 04:55:04PM +0200, Jan Kara wrote:
> > > Different filesystems account different amount of metadata in quota. Thus it is
> > > impractical to check for a particular amount of space occupied by a file
> > > because there is no right value. Change the test to verify whether the amount
> > > of space before quotacheck and after quotacheck is the same as other quota
> > > tests do.
> > 
> > Except that the purpose of the test the accounting correctly matches
> > the blocks allocated via direct IO, buffered IO and mmap, not that
> > quota is consistent over a remount.
> > 
> > IOWs, The numbers do actually matter - for example the recent
> > changes to speculative delayed allocation beyond EOF for buffered IO
> > in XFS could be causing large numbers of blocks to be left after EOF
> > incorrectly, but the exact block number check used in the test would
> > catch that. The method you propose would not catch it at all, and
> > we'd be oblivous to an undesirable change in behaviour.
>   Hmm, I guess we think of different errors to catch with the test. I was
> more thinking that the test tries to catch errors where we forget to
> account allocated blocks in quota or so. But you are right, there are other
> tests to catch this although not testing e.g. direct IO I think.
> 
> > IMO, a better filter function would be the way to go - one
> > that takes into account that there might be some metadata blocks
> > allocated but not less than 3x48k should have be allocated to the
> > quotas...
>   OK, but if I just check that the amount of space is >= 3x48k, your
> sample problem with xfs would pass anyway.

Not if it was done like we do with the randholes tests (008), where we use
the _within_tolerance function to determine if the number of holes is
accceptible.

>
> What would be nice is to know
> the right value but that depends on fs type and also fs parameters (fs
> block size in ext3/ext4) so it would be a bit large chunk of code to
> compute the right value - that's why I chose quotacheck to do the work for
> me...  But I guess I can do that if you think it's worth it.

Yes, block size will alter the number of blocks, but remember that
requota is reporting it in kilobytes, so the number should always be
around 144. Hence checking the result is 144 +/- 5% would probably
cover all filesystems and all configurations without an issue, and
it would still catch gross increasing in disk usage...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs