public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Dave Chinner <david@fromorbit.com>
Cc: Jan Kara <jack@suse.cz>, xfs@oss.sgi.com
Subject: Re: [PATCH] xfstests: Improve test 219 to work with all filesystems
Date: Wed, 18 May 2011 10:24:22 +0200	[thread overview]
Message-ID: <20110518082422.GD25632@quack.suse.cz> (raw)
In-Reply-To: <20110517231301.GX19446@dastard>

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. 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.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

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

  reply	other threads:[~2011-05-18  8:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-17 14:55 [PATCH] xfstests: Improve test 219 to work with all filesystems Jan Kara
2011-05-17 23:13 ` Dave Chinner
2011-05-18  8:24   ` Jan Kara [this message]
2011-05-18 23:43     ` Dave Chinner
2011-05-19 10:49       ` Jan Kara
2011-05-19 11:15         ` Dave Chinner
2011-05-19 11:50           ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110518082422.GD25632@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=david@fromorbit.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox