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