xfs
[Top] [All Lists]

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

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 44/49] xfs: Reduce allocations during CIL insertion
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Mon, 29 Jul 2013 09:15:16 -0500
Cc: "Michael L. Semon" <mlsemon35@xxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130728011255.GY13468@dastard>
References: <1374215120-7271-1-git-send-email-david@xxxxxxxxxxxxx> <1374215120-7271-45-git-send-email-david@xxxxxxxxxxxxx> <51EEF26F.5040001@xxxxxxx> <51EEF949.9020104@xxxxxxxxx> <51EFD68A.40400@xxxxxxx> <51F2E011.5020904@xxxxxxxxx> <51F2E4DD.4020301@xxxxxxx> <20130727015822.GV13468@dastard> <51F41250.9010703@xxxxxxx> <20130728011255.GY13468@dastard>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
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.

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