Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[ASSERT\s+failure\]\s+transaction\s+reservations\s+changes\s+bad\?\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[ASSERT\s+failure\]\s+transaction\s+reservations\s+changes\s+bad\?\s*$/: 13 ]

Total 13 documents matching your query.

1. [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 12 Mar 2013 17:20:02 +1100; Folks, I just got this ASSERT failure running xfstests on a 3.1.8 xfsprogs and a 3.9-rc1 kernel running test 297: [ 2593.733005] XFS: Assertion failed: BTOBB(need_bytes) < log->l_logBBsize, file: fs/; /archives/xfs/2013-03/msg00273.html (10,936 bytes)
2. Re: [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 12 Mar 2013 17:25:31 +1100; FYI, it's 100% reproducable here with: (reproduced on multiple VMs now with the same command line) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx; /archives/xfs/2013-03/msg00274.html (13,277 bytes)
3. Re: [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Jeff Liu <jeff.liu@xxxxxxxxxx>; Date: Tue, 12 Mar 2013 16:08:20 +0800; Hi Dave, I just did a quick verification. mkfs.xfs version 3.1.8 Linux koala 3.9.0-rc1 #80 SMP Tue Mar 12 15:06:39 CST 2013 x86_64 x86_64 x86_64 GNU/Linux meta-data=/dev/sda6 isize=256 agcount=4, ags; /archives/xfs/2013-03/msg00278.html (14,540 bytes)
4. Re: [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 12 Mar 2013 21:31:38 +1100; .... That's a different mkfs.xfs config to what test 297 is using. Different log size, different AG count, no log stripe unit, etc. 297 is using: scratch_mkfs_xfs -d agcount=16,su=256k,sw=12 -l su=25; /archives/xfs/2013-03/msg00282.html (12,050 bytes)
5. Re: [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Jeff Liu <jeff.liu@xxxxxxxxxx>; Date: Tue, 12 Mar 2013 19:05:43 +0800; Sure, verified against a new built 3.8.0 kernel, so this should be a regression issue. $ uname -a Linux koala 3.8.0 #81 SMP Tue Mar 12 18:03:44 CST 2013 x86_64 x86_64 x86_64 GNU/Linux Thanks, -Jeff; /archives/xfs/2013-03/msg00287.html (12,698 bytes)
6. Re: [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Jeff Liu <jeff.liu@xxxxxxxxxx>; Date: Tue, 12 Mar 2013 19:56:35 +0800; More info, 3.7.0 is the oldest kernel on my environment, I ran into the same problem. Thanks, -Jeff; /archives/xfs/2013-03/msg00289.html (14,084 bytes)
7. Re: [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 12 Mar 2013 23:05:45 +1100; Thanks for following up so quickly, Jeff. So the problem is that a new test is tripping over a bug that has been around for a while, not that it is a new regression. OK, so I'll expunge that from my; /archives/xfs/2013-03/msg00290.html (9,346 bytes)
8. Re: [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Jeff Liu <jeff.liu@xxxxxxxxxx>; Date: Tue, 26 Mar 2013 18:14:30 +0800; I did some further tests to nail down this issue, just posting the analysis result here, it might be of some use when we revising it again. The disk is formated with Dave's previous comments, i.e. mk; /archives/xfs/2013-03/msg00745.html (21,963 bytes)
9. Re: [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Mark Tinguely <tinguely@xxxxxxx>; Date: Tue, 26 Mar 2013 11:44:07 -0500; On 03/26/13 05:14, Jeff Liu wrote: On 03/12/2013 08:05 PM, Dave Chinner wrote: On Tue, Mar 12, 2013 at 07:56:35PM +0800, Jeff Liu wrote: More info, 3.7.0 is the oldest kernel on my environment, I ran; /archives/xfs/2013-03/msg00748.html (22,382 bytes)
10. Re: [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Wed, 27 Mar 2013 13:03:31 +1100; If you mount 2.6.39 with "-o nodelaylog", does the problem go away? That's what I suspected was the problem. i.e. that the log was too small for the given configuration. The question is this: how muc; /archives/xfs/2013-03/msg00759.html (12,171 bytes)
11. Re: [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Jeff Liu <jeff.liu@xxxxxxxxxx>; Date: Thu, 28 Mar 2013 20:58:15 +0800; Sorry for my late response. Yes, it need 3531 blocks, but only 2560 blocks is reserved for the logspace. 927 blocks(i.e. max_tr_res * XFS_MIN_LOG_FACTOR) which can be detected at mkfs stage. But the; /archives/xfs/2013-03/msg00799.html (25,737 bytes)
12. Re: [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Jeff Liu <jeff.liu@xxxxxxxxxx>; Date: Thu, 28 Mar 2013 23:16:17 +0800; touch file is ok, but create directory still cause the assertion failure. I still need some time to understand the space reservation strategy to figure them out. :( Thanks, -Jeff; /archives/xfs/2013-03/msg00803.html (13,129 bytes)
13. Re: [ASSERT failure] transaction reservations changes bad? (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 29 Mar 2013 14:00:34 +1100; So it is not related to the way that delayed logging steals reservations for the CIL context checkpoint as the problem still occurs when delayed logging is disabled. That means it is likely to be rel; /archives/xfs/2013-03/msg00823.html (13,867 bytes)

Current List: 1 - 13
Page: [1]