[Top] [All Lists]

Re: [PATCH] xfstests XFS: verify extended attributes after multi-stream

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfstests XFS: verify extended attributes after multi-stream xfsdump/xfsrestore
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Tue, 08 Oct 2013 14:57:29 -0500
Cc: Rich Johnston <rjohnston@xxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131008192701.GZ4446@dastard>
References: <524AF8AE.5030300@xxxxxxx> <20131007193912.256265551@xxxxxxx> <20131008005317.GU4446@dastard> <52535864.8020503@xxxxxxxxxxx> <525414D9.10308@xxxxxxx> <20131008192701.GZ4446@dastard>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
On 10/8/13 2:27 PM, Dave Chinner wrote:
> On Tue, Oct 08, 2013 at 09:21:13AM -0500, Rich Johnston wrote:
>> On 10/07/2013 07:57 PM, Eric Sandeen wrote:
>>> On 10/7/13 7:53 PM, Dave Chinner wrote:
>>>> Two tests, please. move all the common parts into common/dump, and
>>>> write them as two separate tests. That way we can easily track what
>>>> test is failing just by looking at what harness test is failing...
>>> I'm not quite convinced that it's 2 separate tests, TBH.
>>> It's the same root cause; I guess there is a slightly different
>>> outcome because if you hit the same root cause enough times,
>>> you'll segfault.
>> Multiple DMF offline files are successfully restored but the attrs
>> are lost. I wanted to show/test that case.
>> I agree with Eric that it is the same  root cause but because can
>> occur with successful dumps and does not segfault,  Thats why the 2
>> tests.
> Ok, the problem might be triggering the same root cause, but in the
> case of unit tests that is usually irrelevant. That is each individual test
> should be independently tracked by the test harness regardless of
> the bug it triggers.
> And reading on #xfs, the problem isn't clearly understood yet as
> both you and Eric are not sure exactly why there are differences in
> behaviour between different tests yet. e.g:
> [09/10/13 02:13] <rjohnston1> Ahh OK but my DMF test case had several 
> wholly-sparse (offline files) and the dump succeeded. 
> [09/10/13 02:18] <sandeen> tbh there is one thing I'm not clear on here, why 
> a 1t sparse file behaves differently from a 1k sparse file
> [09/10/13 02:18] <sandeen> that seems . .  wrong
> [09/10/13 02:19] <sandeen> but I guess it must just key on i_size, not blocks
> [09/10/13 02:19] <sandeen> so anyway, maybe your dmf testcase had smaller 
> file sizes?
> [09/10/13 02:19] <sandeen> sorry, I have to run & get missed homework to my 
> kid @ school, bbiab.  Grr.
> [09/10/13 02:20] <rjohnston1> NP, yes they were smaller.
> [09/10/13 02:22] <rjohnston1> 100 10MB files no segfault, just trashed attrs.

But that's a testcase not yet written.  ;)  

I do understand why there is a difference between Rich's 1-file test and the 
4-file test.  If you'd like to review the patch that fixes the root cause it 
might be more cleaer.

Between the 1 file & 4 files, the difference is that if we hit the root bug 
enough times, it will fill the partial-completion array, run out of slots, and 
return an error.  That error isn't handled and we get a segfault; I guess 
that's enough of a separate bug to warrant 2 tests.  One to be sure we handle 
the sparse files, and a second to test the error handling from this function if 
we hit the first bug enough times & return an error.

I _don't_ know how Rich/SGI managed to hit it with only 10MB files - I'm not 
clear on when xfsdump splits across streams.
Since that's Rich's bug I'll let him work that out.  ;)


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