On Mon, Jul 29, 2013 at 09:15:16AM -0500, Mark Tinguely wrote:
> 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"?
> >>Micheal found the problem using a simple copy, so I am using copy-like test.
> 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).
Which size calculation is wrong? t~he one used to size the buffer
being allocated - which is intentionally oversized for the inode
forks - or the actual size formatted into the buffer, which was
I mean, 164 bytes is an inode core (96 bytes) plus a inode log
format structure. The increase of 140 bytes indicates that we are
logging roughly the entire 256 byte inode - i.e. both forks.
But are you looking at the size returned by iop_size or iop_format?
iop_size will be new, iop_format is unchanged by this patchset.
indeed, what iop_format returns as vectors is *unchanged* by this
patchset, so I think that you are chasing down the wrong path here.
> I will see if I can substitute the nbytes for len (without
> triggering the ptr being exceeded assert) to see that will cause the
I know what the problem is will be, and that won't fix it. Hint: the
buffer is over sized.