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

[Jan Kara <jack@suse.cz>]

On Thu 19-05-11 21:15:21, Dave Chinner wrote:
> On Thu, May 19, 2011 at 12:49:08PM +0200, Jan Kara wrote:
> > On Thu 19-05-11 09:43:18, Dave Chinner wrote:
> > > 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...
> >   Ah, OK, that makes sense and works for the common cases I'm aware of (it
> > won't work for example for ext4 with 64k block size, or ocfs2 with large
> > cluster size where allocation unit can be upto 1M). Anyway, it has probably
> > the best effort/result ratio so I'll do this. Thanks for ideas.
> 
> The write size of 48k is completely arbitrary, so if we need to
> change it to work better with larger block sizes, then that is
> easy to do...
> 
> Anyway, there are lots of other tests that will break with 64k block
> sizes, so this is the least of our worries at this point...
  Yes, I think that as well. So when we come across a case we want to test
which will fail, we can change the amount written. So far I just changed
the test so that it works for my ext3 & ext4 tests...

								Honza

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