Re: [PATCH 44/49] xfs: Reduce allocations during CIL insertion

Dave Chinner
2013-07-28T01:12:59Z

On Sat, Jul 27, 2013 at 01:32:48PM -0500, Mark Tinguely wrote:
> On 07/26/13 20:58, Dave Chinner wrote:
> >On Fri, Jul 26, 2013 at 04:06:37PM -0500, Mark Tinguely wrote:
> >>
> >>I can reproduce a problem in patch 44 too. It takes my copy test 20
> >>minutes to deplete the log space with patch 44, Same test with patch
> >>43 has been running a day and a half. I do not think that patch 44
> >>is 100 times faster than patch 43 but I will let patch 43 spin all
> >>weekend on a couple machines to verify that patch 43 does not hang.
> >
> >Details, please. What's your "copy test"?
> >
> >http://xfs.org/index.php/XFS_FAQ#Q:_What_information_should_I_include_when_reporting_a_problem.3F
> >
> >Cheers,
> >
> >Dave.
>
> Micheal found the problem using a simple copy, so I am using copy-like test.
>
> I have hung patch 44 with fsstress but I am currently using the
> simple perl scripts from bugzilla bug 922, but I do not do the silly
> step of reducing the log to an abnormal amount.
>
> Just mkfs the filesystem
>
> Create the the test files. the creation script:
> http://oss.sgi.com/bugzilla/attachment.cgi?id=304
>
> Run the test script:
> http://oss.sgi.com/bugzilla/attachment.cgi?id=305
> ----
> This test seems to stress the log much like xfstest 273 only it runs
> forever.

Ok, thanks, for the info, Mark. I'll try to reproduce it here. FWIW,
we should probably add this to xfstests as a "stress" test. i.e. not
part of the auto group, but something that uses the scale parameters
to determine runtime. then add all the other tests that have scale
parameters to the same group, and if we run ./check --stress <scale>
it runs through all the stress tests with that given scale factor...

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com