xfs
[Top] [All Lists]

Re: group for tests that are dangerous for verifiers?

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: group for tests that are dangerous for verifiers?
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 24 Jun 2013 08:50:53 +1000
Cc: Mark Tinguely <tinguely@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <51C49F5A.3020907@xxxxxxxxxxx>
References: <51C341E1.8000302@xxxxxxx> <51C49F5A.3020907@xxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Jun 21, 2013 at 01:45:46PM -0500, Eric Sandeen wrote:
> On 6/20/13 12:54 PM, Mark Tinguely wrote:
> > Do we need a xfstest verifier dangerous group?
> > 
> > xfstest 111 purposely damages inodes. In hindsight it make sense
> > that it asserts when running with verifiers.
> 
> But it only asserts on a debug kernel... 

Right, and it has done so for years - blaming verifiers for
triggering the assert failure is simply shooting the messenger.

> This isn't the only place where corruption could ASSERT on debug;
> see xlog_recover_add_to_trans() for example.
> 
> But if the test intentionally corrupts it and that leads to
> an ASSERT that does seem problematic for anyone testing w/ debug
> enabled.

Yup, it runs src/itrash.c which corrupts every inode it can find.

That's the reason this test is not part of the auto group - it's
a test that will cause the system to stop. We've got other tests
that are not part of the auto group for exactly the same reason -
they cause some kind of terminal failure and so aren't candidates
for regression testing.

> I guess I'd vote for removing the ASSERT unless there's
> some reason it should be there - Dave?

I'm fine with it being removed - we catch the failure just fine. If
that then makes 111 work as a regression test (i.e. doesn't trigger
the bad-inode bulkstat loop it was designed to test) then perhaps we
can consider making that part of the auto group, too...

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>