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.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
