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