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
OK, but if I just check that the amount of space is >= 3x48k, your
sample problem with xfs would pass anyway. 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.
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR