public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Alex Elder <aelder@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] [RFC] xfstests: deprecate busted log printing tests
Date: Thu, 21 Jan 2010 08:27:10 +1100	[thread overview]
Message-ID: <20100120212710.GK14035@discord.disaster> (raw)
In-Reply-To: <1AB9A794DBDDF54A8A81BE2296F7BDFE012A69A1@cf--amer001e--3.americas.sgi.com>

On Wed, Jan 20, 2010 at 09:53:27AM -0600, Alex Elder wrote:
> Dave Chinner wrote:
> > Tests 018, 081 and 082 read the contents of the log and assume that the
> > contents will always be the same. They are trying to ensure that the
> > contents of the log don't change for a given fixed load.
> > 
> > This has several problems - high level changes to the filesystem and
> > VFS code can change the order and contents of the log. Changes to
> > the way we sync the filesystem will change the contents of the log.
> > background writeback occurring in the middle of the test will change
> > the contents of the log by allowing the tail to move. Even changes
> > to the default mkfs parameters can break them!
> > 
> > The tests also assume that unmount leaves a dirty log behind. We've
> > fixed lots of problems in sync and the unmount paths over recent
> > times, so now a clean unmount leaves a clean log behind. That is,
> > there is nothing left in the log print output for these tests to
> > check. IOWs, major surgery is required for these tests to be
> > returned to their former break-when-something-changes behaviour.
> > 
> > However, these tests are a maintenance nightmare. They spend more
> > time broken and failing than they do passing, and then it's not long
> > before they get broken again. They have to cover all sorts of
> > different permutations of log configurations and that will continue
> > to grow and increase the complexity of making these tests continue
> > to work. And to top it all off, I can't remember a bug actually ever
> > being found by these tests. Hence I think we should just stop using
> > them altogether.
> > 
> > So this patch deprecates 018, 081 and 082 rather than fixes them.
> > It introduces a "deprecated" test group and puts them in it. That
> > means the tests can still be run on older systems where they may
> > have some use, but will not be run automatically any more, nor
> > will any attempt be made to keep them up to date or working.
> 
> I think this is a reasonable thing to do.  My only thought
> is that it might be good to somehow indicate *when* or *why*
> something got deprecated.

That is what the commit message is for ;)

i.e. use git blame to find the commit that marked a test deprecated
and then go read the commit message, which in this case would be all
of the above...

Cheers,

Dave.

-- 
Dave Chinner
david@fromorbit.com

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

      reply	other threads:[~2010-01-20 21:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-20  5:59 [PATCH] [RFC] xfstests: deprecate busted log printing tests Dave Chinner
2010-01-20  8:33 ` Christoph Hellwig
2010-01-20 15:53 ` Alex Elder
2010-01-20 21:27   ` Dave Chinner [this message]

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=20100120212710.GK14035@discord.disaster \
    --to=david@fromorbit.com \
    --cc=aelder@sgi.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