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

Mark Tinguely
2013-07-29T14:15:20Z

On 07/27/13 20:12, Dave Chinner wrote:
> 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.

BTW, the long term run of the copy.pl from bug 922 with patch 43 results:
tail 0x601000055d7
grant/reserve 0x60100abb200
ctx t_unit_res 0x834

My log math may be off, tail/reserve diff is 1024, but the CTX holds
more than that (2100 bytes).

Looking at patch 44, it is the first time we use the calculation for the
number of bytes in patch 43. So I am looking at where the new
calculation in iop_size differs from the previous len calculation in
xlog_cil_prepare_log_vecs(). So far, I am that inode entry is 140 bytes
larger with the new calculation (former len 164 vrs new nbytes 304 type
123b - non-crc filesystem).

I will see if I can substitute the nbytes for len (without triggering
the ptr being exceeded assert) to see that will cause the hang.

--Mark.