Hi everyone, I''ve pushed out a new integration branch, but it is not for general use. I''m still going through and hammering on the new logging code code to make sure it is properly backwards compatible with older kernels and that it hasn''t introduced any new bugs. *** Please do not use this code on anything other than test filesystems that can easily be reformatted. *** In testing the new sub-transid logging code, I''ve spent a lot of time hunting logging bugs, and writing new tests to try and make sure the logging code is working correctly in general. Between that and some new tests from Arne, I''ve had to make some pretty big changes to the code. This meant collapsing Fujitsu''s original nicely broken out patches into a larger patch so that I could be sure later kernel bisections wouldn''t run into problems. All credit to Liu Bo and Fujitsu for getting the sub-transid work going, any bugs in the pushed patch are probably ones I introduced. integration-danger merges in the new sub-transid logging code along with all of the fixes Dave Sterba has been tracking, and Josef''s code. I''m still merging in trees from Arne and Jan Schmidt, those should get pushed out tomorrow afternoon. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On 11/01/2011 10:49 AM, Chris Mason wrote:> Hi everyone, > > I''ve pushed out a new integration branch, but it is not for general use. > > I''m still going through and hammering on the new logging code code to > make sure it is properly backwards compatible with older kernels and > that it hasn''t introduced any new bugs. > > *** Please do not use this code on anything other than test filesystems that > can easily be reformatted. *** > > In testing the new sub-transid logging code, I''ve spent a lot of time > hunting logging bugs, and writing new tests to try and make sure the > logging code is working correctly in general. Between that and some new > tests from Arne, I''ve had to make some pretty big changes to the code. >I''m giving a hard read on the new code, and I notice a slight change: @@ -3006,14 +3179,11 @@ out: static int inode_in_log(struct btrfs_trans_handle *trans, struct inode *inode) { - struct btrfs_root *root = BTRFS_I(inode)->root; int ret = 0; - mutex_lock(&root->log_mutex); - if (BTRFS_I(inode)->logged_trans == trans->transid && - BTRFS_I(inode)->last_sub_trans <= root->last_log_commit) + if (BTRFS_I(inode)->logged_trans >= trans->transaction->transid && + BTRFS_I(inode)->last_trans < BTRFS_I(inode)->logged_trans) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ret = 1; - mutex_unlock(&root->log_mutex); return ret; } since we''ve moved the "sub_transid++" update to btrfs_sync_log(), the ending of log, say there is a case like this: transaction ------------------------------------------ start | sub_trans A | --- start | | --- modify inode X, and set X''s last_trans to sub_transid | | | | --- fsync inode X, and set X''s logged_trans to sub_transid | | | | --- in btrfs_sync_log(), sub_transid++ | | \|/ | --- end | sub_trans A+1 | --- start | | --- no change to inode X | | --- fsync inode X | | --- in inode_in_log(), X''s last_trans is equal to X''s logged_trans, unchanged X is just in the log, but we need to log X again. ...... ...... transaction ------------------------------------------ end we do not want this, does we? Or am I missing something? thanks, liubo> This meant collapsing Fujitsu''s original nicely broken out patches into > a larger patch so that I could be sure later kernel bisections wouldn''t > run into problems. All credit to Liu Bo and Fujitsu for getting the > sub-transid work going, any bugs in the pushed patch are probably ones > I introduced. > > integration-danger merges in the new sub-transid logging code along with > all of the fixes Dave Sterba has been tracking, and Josef''s code. > > I''m still merging in trees from Arne and Jan Schmidt, those should get > pushed out tomorrow afternoon. > > -chris > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Sterba
2011-Nov-01 10:11 UTC
Warnings (was: Re: new integration-danger branch pushed out (kernel))
Hi, On Mon, Oct 31, 2011 at 10:49:57PM -0400, Chris Mason wrote:> I''ve pushed out a new integration branch, but it is not for general use.Thank you! xfstests/083 and 089 cause the following warnings. I''ve seen them before when testing josef/for-chris and josef/master branches (reported on irc). [ 1149.108088] ------------[ cut here ]------------ [ 1149.114384] WARNING: at fs/btrfs/extent-tree.c:3932 btrfs_free_block_groups+0x304/0x320 [btrfs]() [ 1149.124928] Hardware name: Santa Rosa platform [ 1149.124931] Modules linked in: loop btrfs aoe [ 1149.124938] Pid: 23991, comm: umount Not tainted 3.1.0-default+ #64 [ 1149.124941] Call Trace: [ 1149.124950] [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0 [ 1149.124953] [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20 [ 1149.124973] [<ffffffffa002bba4>] btrfs_free_block_groups+0x304/0x320 [btrfs] [ 1149.124985] [<ffffffffa0036ab9>] close_ctree+0x1e9/0x390 [btrfs] [ 1149.124991] [<ffffffff8115e2df>] ? dispose_list+0x4f/0x60 [ 1149.124999] [<ffffffffa00108dd>] btrfs_put_super+0x1d/0x30 [btrfs] [ 1149.125003] [<ffffffff81145202>] generic_shutdown_super+0x62/0xe0 [ 1149.125006] [<ffffffff81145316>] kill_anon_super+0x16/0x30 [ 1149.125009] [<ffffffff811461a2>] ? deactivate_super+0x42/0x70 [ 1149.125012] [<ffffffff811456dd>] deactivate_locked_super+0x3d/0xa0 [ 1149.125015] [<ffffffff811461aa>] deactivate_super+0x4a/0x70 [ 1149.125019] [<ffffffff81162972>] mntput_no_expire+0xa2/0xf0 [ 1149.125022] [<ffffffff811636df>] sys_umount+0x6f/0x390 [ 1149.125027] [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b [ 1149.125030] ---[ end trace 81d2bc6c70d7ca56 ]--- [ 1149.125032] ------------[ cut here ]------------ [ 1149.125041] WARNING: at fs/btrfs/extent-tree.c:3933 btrfs_free_block_groups+0x2ee/0x320 [btrfs]() [ 1149.125044] Hardware name: Santa Rosa platform [ 1149.125045] Modules linked in: loop btrfs aoe [ 1149.125049] Pid: 23991, comm: umount Tainted: G W 3.1.0-default+ #64 [ 1149.125051] Call Trace: [ 1149.125054] [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0 [ 1149.125057] [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20 [ 1149.125067] [<ffffffffa002bb8e>] btrfs_free_block_groups+0x2ee/0x320 [btrfs] [ 1149.125078] [<ffffffffa0036ab9>] close_ctree+0x1e9/0x390 [btrfs] [ 1149.125081] [<ffffffff8115e2df>] ? dispose_list+0x4f/0x60 [ 1149.125089] [<ffffffffa00108dd>] btrfs_put_super+0x1d/0x30 [btrfs] [ 1149.125092] [<ffffffff81145202>] generic_shutdown_super+0x62/0xe0 [ 1149.125096] [<ffffffff81145316>] kill_anon_super+0x16/0x30 [ 1149.125099] [<ffffffff811461a2>] ? deactivate_super+0x42/0x70 [ 1149.125102] [<ffffffff811456dd>] deactivate_locked_super+0x3d/0xa0 [ 1149.125105] [<ffffffff811461aa>] deactivate_super+0x4a/0x70 [ 1149.125108] [<ffffffff81162972>] mntput_no_expire+0xa2/0xf0 [ 1149.125111] [<ffffffff811636df>] sys_umount+0x6f/0x390 [ 1149.125115] [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b [ 1149.125117] ---[ end trace 81d2bc6c70d7ca57 ]--- The code in question: 3927 static void release_global_block_rsv(struct btrfs_fs_info *fs_info) 3928 { 3929 block_rsv_release_bytes(&fs_info->global_block_rsv, NULL, (u64)-1); 3930 WARN_ON(fs_info->delalloc_block_rsv.size > 0); 3931 WARN_ON(fs_info->delalloc_block_rsv.reserved > 0); 3932 WARN_ON(fs_info->trans_block_rsv.size > 0); 3933 WARN_ON(fs_info->trans_block_rsv.reserved > 0); 3934 WARN_ON(fs_info->chunk_block_rsv.size > 0); 3935 WARN_ON(fs_info->chunk_block_rsv.reserved > 0); 3936 } [ 1149.125119] ------------[ cut here ]------------ [ 1149.125128] WARNING: at fs/btrfs/extent-tree.c:7090 btrfs_free_block_groups+0x23b/0x320 [btrfs]() [ 1149.125130] Hardware name: Santa Rosa platform [ 1149.125131] Modules linked in: loop btrfs aoe [ 1149.125135] Pid: 23991, comm: umount Tainted: G W 3.1.0-default+ #64 [ 1149.125137] Call Trace: [ 1149.125140] [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0 [ 1149.125143] [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20 [ 1149.125153] [<ffffffffa002badb>] btrfs_free_block_groups+0x23b/0x320 [btrfs] [ 1149.125164] [<ffffffffa0036ab9>] close_ctree+0x1e9/0x390 [btrfs] [ 1149.125167] [<ffffffff8115e2df>] ? dispose_list+0x4f/0x60 [ 1149.125175] [<ffffffffa00108dd>] btrfs_put_super+0x1d/0x30 [btrfs] [ 1149.125178] [<ffffffff81145202>] generic_shutdown_super+0x62/0xe0 [ 1149.125181] [<ffffffff81145316>] kill_anon_super+0x16/0x30 [ 1149.125184] [<ffffffff811461a2>] ? deactivate_super+0x42/0x70 [ 1149.125187] [<ffffffff811456dd>] deactivate_locked_super+0x3d/0xa0 [ 1149.125191] [<ffffffff811461aa>] deactivate_super+0x4a/0x70 [ 1149.125194] [<ffffffff81162972>] mntput_no_expire+0xa2/0xf0 [ 1149.125197] [<ffffffff811636df>] sys_umount+0x6f/0x390 [ 1149.125200] [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b [ 1149.125202] ---[ end trace 81d2bc6c70d7ca58 ]--- [ 1149.125206] space_info 5 has 4931584 free, is full [ 1149.125208] space_info total=48234496, used=43302912, pinned=0, reserved=0, may_use=294912, readonly=0 7028 int btrfs_free_block_groups(struct btrfs_fs_info *info) ... 7083 while(!list_empty(&info->space_info)) { 7084 space_info = list_entry(info->space_info.next, 7085 struct btrfs_space_info, 7086 list); 7087 if (space_info->bytes_pinned > 0 || 7088 space_info->bytes_reserved > 0 || 7089 space_info->bytes_may_use > 0) { 7090 WARN_ON(1); 7091 dump_space_info(space_info, 0, 0); 7092 } 7093 list_del(&space_info->list); 7094 kfree(space_info); 7095 } 7096 return 0; 7097 } david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Sterba
2011-Nov-01 10:28 UTC
Warnings: destroy inode (was: new integration-danger branch pushed out (kernel))
this time I''m not quite sure which xfstest triggered it, but there was
209 35s ... [11:20:19] [11:20:53] [failed, exit status 1] - output mismatch
(see 209.out.bad)
--- 209.out 2011-02-11 11:42:31.000000000 +0100
+++ 209.out.bad 2011-11-01 11:20:53.000000000 +0100
@@ -1,2 +1,2 @@
QA output created by 209
-test ran for 30 seconds without error
+reader found old byte at pos 7380992
\ No newline at end of file
[ 3134.165501] ------------[ cut here ]------------
[ 3134.171488] WARNING: at fs/btrfs/inode.c:6789 btrfs_destroy_inode+0x315/0x350
[btrfs]()
[ 3134.180812] Hardware name: Santa Rosa platform
[ 3134.180814] Modules linked in: loop btrfs aoe
[ 3134.180820] Pid: 26264, comm: rm Tainted: G W 3.1.0-default+ #64
[ 3134.180822] Call Trace:
[ 3134.180829] [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 3134.180832] [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 3134.180845] [<ffffffffa0048165>] btrfs_destroy_inode+0x315/0x350
[btrfs]
[ 3134.180850] [<ffffffff8115db3c>] destroy_inode+0x3c/0x70
[ 3134.180853] [<ffffffff8115dc8e>] evict+0x11e/0x1c0
[ 3134.180855] [<ffffffff8115de3d>] iput+0x10d/0x210
[ 3134.180859] [<ffffffff8115240f>] do_unlinkat+0x16f/0x1d0
[ 3134.180863] [<ffffffff81a15319>] ? retint_swapgs+0x13/0x1b
[ 3134.180867] [<ffffffff81097bd5>] ?
trace_hardirqs_on_caller+0x155/0x1d0
[ 3134.180872] [<ffffffff8135c9be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 3134.180875] [<ffffffff811532b2>] sys_unlinkat+0x22/0x40
[ 3134.180879] [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
[ 3134.180882] ---[ end trace 81d2bc6c70d7ca5c ]---
[ 3134.180883] ------------[ cut here ]------------
[ 3134.180895] WARNING: at fs/btrfs/inode.c:6790 btrfs_destroy_inode+0x2ff/0x350
[btrfs]()
[ 3134.180897] Hardware name: Santa Rosa platform
[ 3134.180899] Modules linked in: loop btrfs aoe
[ 3134.180903] Pid: 26264, comm: rm Tainted: G W 3.1.0-default+ #64
[ 3134.180905] Call Trace:
[ 3134.180908] [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 3134.180911] [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 3134.180923] [<ffffffffa004814f>] btrfs_destroy_inode+0x2ff/0x350
[btrfs]
[ 3134.180927] [<ffffffff8115db3c>] destroy_inode+0x3c/0x70
[ 3134.180929] [<ffffffff8115dc8e>] evict+0x11e/0x1c0
[ 3134.180933] [<ffffffff8115de3d>] iput+0x10d/0x210
[ 3134.180936] [<ffffffff8115240f>] do_unlinkat+0x16f/0x1d0
[ 3134.180939] [<ffffffff81a15319>] ? retint_swapgs+0x13/0x1b
[ 3134.180942] [<ffffffff81097bd5>] ?
trace_hardirqs_on_caller+0x155/0x1d0
[ 3134.180945] [<ffffffff8135c9be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 3134.180948] [<ffffffff811532b2>] sys_unlinkat+0x22/0x40
[ 3134.180952] [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
[ 3134.180954] ---[ end trace 81d2bc6c70d7ca5d ]---
[ 3134.180956] ------------[ cut here ]------------
[ 3134.180967] WARNING: at fs/btrfs/inode.c:6792 btrfs_destroy_inode+0x2d3/0x350
[btrfs]()
[ 3134.181008] Hardware name: Santa Rosa platform
[ 3134.181010] Modules linked in: loop btrfs aoe
[ 3134.181014] Pid: 26264, comm: rm Tainted: G W 3.1.0-default+ #64
[ 3134.181016] Call Trace:
[ 3134.181019] [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 3134.181023] [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 3134.181035] [<ffffffffa0048123>] btrfs_destroy_inode+0x2d3/0x350
[btrfs]
[ 3134.181038] [<ffffffff8115db3c>] destroy_inode+0x3c/0x70
[ 3134.181041] [<ffffffff8115dc8e>] evict+0x11e/0x1c0
[ 3134.181043] [<ffffffff8115de3d>] iput+0x10d/0x210
[ 3134.181046] [<ffffffff8115240f>] do_unlinkat+0x16f/0x1d0
[ 3134.181049] [<ffffffff81a15319>] ? retint_swapgs+0x13/0x1b
[ 3134.181052] [<ffffffff81097bd5>] ?
trace_hardirqs_on_caller+0x155/0x1d0
[ 3134.181055] [<ffffffff8135c9be>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[ 3134.181059] [<ffffffff811532b2>] sys_unlinkat+0x22/0x40
[ 3134.181062] [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
[ 3134.181064] ---[ end trace 81d2bc6c70d7ca5e ]---
[ 3135.152109] ------------[ cut here ]------------
6782 void btrfs_destroy_inode(struct inode *inode)
6783 {
6784 struct btrfs_ordered_extent *ordered;
6785 struct btrfs_root *root = BTRFS_I(inode)->root;
6786
6787 WARN_ON(!list_empty(&inode->i_dentry));
6788 WARN_ON(inode->i_data.nrpages);
6789 WARN_ON(BTRFS_I(inode)->outstanding_extents);
6790 WARN_ON(BTRFS_I(inode)->reserved_extents);
6791 WARN_ON(BTRFS_I(inode)->delalloc_bytes);
6792 WARN_ON(BTRFS_I(inode)->csum_bytes);
david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Sterba
2011-Nov-01 10:36 UTC
BUG at fs/btrfs/tree-log.c:3106 (Re: new integration-danger branch pushed out (kernel))
xfstests/214
[ 3142.654774] ------------[ cut here ]------------
[ 3142.656017] kernel BUG at fs/btrfs/tree-log.c:3106!
[ 3142.656017] invalid opcode: 0000 [#1] SMP
[ 3142.656017] CPU 0
[ 3142.656017] Modules linked in: loop btrfs aoe
[ 3142.656017]
[ 3142.656017] Pid: 27328, comm: xfs_io Tainted: G W 3.1.0-default+ #64
Intel Corporation Santa Rosa platform/Matanzas
[ 3142.656017] RIP: 0010:[<ffffffffa006fe74>] [<ffffffffa006fe74>]
btrfs_log_inode+0x554/0x600 [btrfs]
[ 3142.656017] RSP: 0018:ffff88005c801d58 EFLAGS: 00010282
[ 3142.656017] RAX: 00000000ffffffef RBX: ffff88003ef39e20 RCX: 0000000000000006
[ 3142.656017] RDX: 0000000000000001 RSI: ffff8800643aa170 RDI: 0000000000000286
[ 3142.656017] RBP: ffff88005c801e48 R08: 0000000000000001 R09: 0000000000000001
[ 3142.656017] R10: 0000000000000001 R11: 0000000000000002 R12: ffff88003405fe70
[ 3142.656017] R13: ffff88005c801db8 R14: 0000000000000003 R15: ffff8800340604b0
[ 3142.656017] FS: 00007f7034667700(0000) GS:ffff88007dc00000(0000)
knlGS:0000000000000000
[ 3142.656017] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3142.656017] CR2: 00000000006b1fb0 CR3: 00000000778df000 CR4: 00000000000006f0
[ 3142.656017] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 3142.656017] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 3142.656017] Process xfs_io (pid: 27328, threadinfo ffff88005c800000, task
ffff8800643a9ac0)
[ 3142.656017] Stack:
[ 3142.656017] 0000000000000000 0000000000000000 ffff8800340602b0
ffff880072efe000
[ 3142.656017] 0000000000000000 00000000000004c8 000000005c801dd8
ffff8800340604b0
[ 3142.656017] ffff88003ef39eb0 ffff88000dfb4420 0000000000000019
0000000000000308
[ 3142.656017] Call Trace:
[ 3142.656017] [<ffffffffa0070d28>] btrfs_log_inode_parent+0x198/0x480
[btrfs]
[ 3142.656017] [<ffffffff8115941c>] ? dget_parent+0x1c/0xd0
[ 3142.656017] [<ffffffffa0071059>] btrfs_log_dentry_safe+0x49/0x70
[btrfs]
[ 3142.656017] [<ffffffffa0049406>] btrfs_sync_file+0x146/0x1d0 [btrfs]
[ 3142.656017] [<ffffffff81143e80>] ? fget_raw+0x210/0x210
[ 3142.656017] [<ffffffff81171029>] do_fsync+0x59/0x80
[ 3142.656017] [<ffffffff81171340>] sys_fsync+0x10/0x20
[ 3142.656017] [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b
[ 3142.656017] Code: 60 ff ff ff 45 89 f1 48 8b bd 58 ff ff ff 4c 89 e1 4c 89 fe
89 14 24 48 8b 95 50 ff ff ff e8 44 cf ff ff 85 c0 0f 84 04 fe ff ff <0f>
0b 48 89 df e8 f2 62 fa ff 48 8b bd 50 ff ff ff e8 e6 62 fa
[ 3142.656017] RIP [<ffffffffa006fe74>] btrfs_log_inode+0x554/0x600
[btrfs]
[ 3142.656017] RSP <ffff88005c801d58>
[ 3142.995743] ---[ end trace 81d2bc6c70d7ca63 ]---
2923 static int btrfs_log_inode(struct btrfs_trans_handle *trans,
2924 struct btrfs_root *root, struct inode *inode,
2925 int inode_only)
2926 {
...
3105 out_unlock:
3106 BUG_ON(err);
3107 mutex_unlock(&BTRFS_I(inode)->log_mutex);
3108
3109 btrfs_free_path(path);
3110 btrfs_free_path(dst_path);
3111 return err;
3112 }
from the value of RAX, -17 it''s EEXIST
the code originates from:
commit 3ff4357398886f277c278fd039ba65abf5e3a113
Author: Liu Bo <liubo2009@cn.fujitsu.com>
Date: Wed Oct 12 20:01:24 2011 -0400
Btrfs: improve log with sub transaction
When logging an inode _A_, current btrfs will
a) clear all items belonged to _A_ in log,
b) copy all items belonged to _A_ from fs/file tree to log tree,
and this just wastes a lot of time, especially when logging big files.
So we want to use a smarter approach, i.e. "find and merge".
The amount of file extent items is the largest, so we focus on it.
Thanks to sub transaction, now we can find those file extent items which
are changed after last _transaction commit_ or last _log commit_, and
then merge them with the existed ones in log tree.
It will be great helpful on fsync performance, cause the common case is
"make changes on a _part_ of inode".
Chris Mason did some reworking of this code, any bugs left are his.
Signed-off-by: Liu Bo <liubo2009@cn.fujitsu.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
---
david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 01, 2011 at 05:22:20PM +0800, Liu Bo wrote:> Hi, > > On 11/01/2011 10:49 AM, Chris Mason wrote: > > Hi everyone, > > > > I''ve pushed out a new integration branch, but it is not for general use. > > > > I''m still going through and hammering on the new logging code code to > > make sure it is properly backwards compatible with older kernels and > > that it hasn''t introduced any new bugs. > > > > *** Please do not use this code on anything other than test filesystems that > > can easily be reformatted. *** > > > > In testing the new sub-transid logging code, I''ve spent a lot of time > > hunting logging bugs, and writing new tests to try and make sure the > > logging code is working correctly in general. Between that and some new > > tests from Arne, I''ve had to make some pretty big changes to the code. > > > > I''m giving a hard read on the new code, and I notice a slight change:Thanks a lot for reading it carefully.> @@ -3006,14 +3179,11 @@ out: > static int inode_in_log(struct btrfs_trans_handle *trans, > struct inode *inode) > { > - struct btrfs_root *root = BTRFS_I(inode)->root; > int ret = 0; > > - mutex_lock(&root->log_mutex); > - if (BTRFS_I(inode)->logged_trans == trans->transid && > - BTRFS_I(inode)->last_sub_trans <= root->last_log_commit) > + if (BTRFS_I(inode)->logged_trans >= trans->transaction->transid && > + BTRFS_I(inode)->last_trans < BTRFS_I(inode)->logged_trans) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ret = 1; > - mutex_unlock(&root->log_mutex); > return ret; > } > > since we''ve moved the "sub_transid++" update to btrfs_sync_log(), the ending of log, > say there is a case like this: > > transaction ------------------------------------------ start > | > sub_trans A | --- start > | > | --- modify inode X, and set X''s last_trans to sub_transid > | | > | | --- fsync inode X, and set X''s logged_trans to sub_transid > | | > | | --- in btrfs_sync_log(), sub_transid++ > | | > \|/ | --- end > | > sub_trans A+1 | --- start > | > | --- no change to inode X > | > | --- fsync inode X > | > | --- in inode_in_log(), X''s last_trans is equal to X''s logged_trans, > unchanged X is just in the log, but we need to log X again. > > ...... ...... > > transaction ------------------------------------------ end > > we do not want this, does we? Or am I missing something?Correct, this is less optimal. I was finding races where the transid increasing at the start of the log trans would lead to one process missing file and directory updates done by another process. So I made the patch slightly more conservative. We''re still logging about 75% less than we used to in every workload I''ve tried, but we can definitely refine this in future commits. Along the way I fixed an old bug in directory logging that meant we almost always force a full commit for directory fsyncs. The fix means we use the directory log more often now, which is faster in some cases and slower in others. It also means a bug with delayed metadata insertion triggers more easily during log replay (we need to flush the delayed ops during log replay). The bug was hidden before because the directory log wasn''t being used much. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Mason
2011-Nov-01 10:56 UTC
Re: BUG at fs/btrfs/tree-log.c:3106 (Re: new integration-danger branch pushed out (kernel))
On Tue, Nov 01, 2011 at 11:36:37AM +0100, David Sterba wrote:> xfstests/214 > > [ 3142.654774] ------------[ cut here ]------------ > [ 3142.656017] kernel BUG at fs/btrfs/tree-log.c:3106!What kind of hardware are you running this on? I''m passing 214 here. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
the related source pointers of the warnings and crash (detailed below):
[ 1186.540073] WARNING: at fs/btrfs/extent-tree.c:5837
btrfs_alloc_free_block+0x337/0x350 [btrfs]()
[ 1186.541076] WARNING: at fs/btrfs/extent-tree.c:4617
__btrfs_free_extent+0x60d/0x6c0 [btrfs]()
[ 1186.541234] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 1186.541237] IP: [<ffffffffa005b881>]
map_private_extent_buffer+0x21/0x1f0 [btrfs]
fs/btrfs/extent-tree.c:5837
This not a new warning, also known as ''the warn in
use_block_rsv'', happened
during xfstests/224.
The ratelimited printk patch (btrfs: ratelimit WARN_ON in use_block_rsv) is
part of the btrfs-next-stable branch pulled in, though is still meant as a
safety not to hang the box completely (and should go away in the future).
[ 1186.529033] btrfs: block rsv returned -28
[ 1186.534256] ------------[ cut here ]------------
[ 1186.540073] WARNING: at fs/btrfs/extent-tree.c:5837
btrfs_alloc_free_block+0x337/0x350 [btrfs]()
[ 1186.540075] Hardware name: Santa Rosa platform
[ 1186.540077] Modules linked in: btrfs aoe
[ 1186.540082] Pid: 5007, comm: btrfs-transacti Not tainted 3.1.0-default+ #64
[ 1186.540084] Call Trace:
[ 1186.540091] [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 1186.540095] [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 1186.540104] [<ffffffffa002a9d7>] btrfs_alloc_free_block+0x337/0x350
[btrfs]
[ 1186.540109] [<ffffffff810913dd>] ? trace_hardirqs_off+0xd/0x10
[ 1186.540113] [<ffffffff810098d5>] ? native_sched_clock+0x15/0x70
[ 1186.540118] [<ffffffff810844ff>] ? local_clock+0x6f/0x80
[ 1186.540126] [<ffffffffa0017162>] __btrfs_cow_block+0x152/0x800 [btrfs]
[ 1186.540130] [<ffffffff810844ff>] ? local_clock+0x6f/0x80
[ 1186.540133] [<ffffffff810916fd>] ? lock_release_holdtime+0x3d/0x1a0
[ 1186.540141] [<ffffffffa0017ae1>] btrfs_cow_block+0x2d1/0x410 [btrfs]
[ 1186.540150] [<ffffffffa001cb88>] btrfs_search_slot+0x728/0xe70 [btrfs]
[ 1186.540159] [<ffffffffa0022f0b>]
lookup_inline_extent_backref+0x8b/0x480 [btrfs]
[ 1186.540168] [<ffffffffa00245f0>] __btrfs_free_extent+0xd0/0x6c0
[btrfs]
[ 1186.540172] [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.540182] [<ffffffffa00287cf>] run_clustered_refs+0x21f/0x850
[btrfs]
[ 1186.540192] [<ffffffffa0028ec8>] btrfs_run_delayed_refs+0xc8/0x220
[btrfs]
[ 1186.540195] [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.540205] [<ffffffffa0029178>]
btrfs_write_dirty_block_groups+0x158/0x540 [btrfs]
[ 1186.540216] [<ffffffffa0038ee5>] commit_cowonly_roots+0x115/0x1e0
[btrfs]
[ 1186.540228] [<ffffffffa0039ee7>] btrfs_commit_transaction+0x477/0x8f0
[btrfs]
[ 1186.540240] [<ffffffffa00391a9>] ? join_transaction+0x69/0x2b0 [btrfs]
[ 1186.540243] [<ffffffff8107d480>] ? wake_up_bit+0x40/0x40
[ 1186.540254] [<ffffffffa0032a1b>] transaction_kthread+0x28b/0x2a0
[btrfs]
[ 1186.540264] [<ffffffffa0032790>] ? btree_readpage+0x30/0x30 [btrfs]
[ 1186.540267] [<ffffffff8107cf16>] kthread+0xa6/0xb0
[ 1186.540272] [<ffffffff81a1ea04>] kernel_thread_helper+0x4/0x10
[ 1186.540276] [<ffffffff81a15334>] ? retint_restore_args+0x13/0x13
[ 1186.540279] [<ffffffff8107ce70>] ? __init_kthread_worker+0x70/0x70
[ 1186.540282] [<ffffffff81a1ea00>] ? gs_change+0x13/0x13
[ 1186.540284] ---[ end trace 6fa3da5fd65420af ]---
[ 1186.540433] btrfs: block rsv returned -28
ratelimited, I see just 2 occurences before, followed by
[ 1186.541076] WARNING: at fs/btrfs/extent-tree.c:4617
__btrfs_free_extent+0x60d/0x6c0 [btrfs]()
[ 1186.541079] Hardware name: Santa Rosa platform
[ 1186.541080] Modules linked in: btrfs aoe
[ 1186.541084] Pid: 5007, comm: btrfs-transacti Tainted: G W
3.1.0-default+ #64
[ 1186.541086] Call Trace:
[ 1186.541089] [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 1186.541093] [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 1186.541101] [<ffffffffa0024b2d>] __btrfs_free_extent+0x60d/0x6c0
[btrfs]
[ 1186.541105] [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.541114] [<ffffffffa0028949>] run_clustered_refs+0x399/0x850
[btrfs]
[ 1186.541126] [<ffffffffa0079800>] ? btrfs_find_ref_cluster+0xb0/0x1a0
[btrfs]
[ 1186.541136] [<ffffffffa0028ec8>] btrfs_run_delayed_refs+0xc8/0x220
[btrfs]
[ 1186.541139] [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.541149] [<ffffffffa0029178>]
btrfs_write_dirty_block_groups+0x158/0x540 [btrfs]
[ 1186.541160] [<ffffffffa0038ee5>] commit_cowonly_roots+0x115/0x1e0
[btrfs]
[ 1186.541172] [<ffffffffa0039ee7>] btrfs_commit_transaction+0x477/0x8f0
[btrfs]
[ 1186.541183] [<ffffffffa00391a9>] ? join_transaction+0x69/0x2b0 [btrfs]
[ 1186.541186] [<ffffffff8107d480>] ? wake_up_bit+0x40/0x40
[ 1186.541196] [<ffffffffa0032a1b>] transaction_kthread+0x28b/0x2a0
[btrfs]
[ 1186.541207] [<ffffffffa0032790>] ? btree_readpage+0x30/0x30 [btrfs]
[ 1186.541210] [<ffffffff8107cf16>] kthread+0xa6/0xb0
[ 1186.541213] [<ffffffff81a1ea04>] kernel_thread_helper+0x4/0x10
[ 1186.541216] [<ffffffff81a15334>] ? retint_restore_args+0x13/0x13
[ 1186.541219] [<ffffffff8107ce70>] ? __init_kthread_worker+0x70/0x70
[ 1186.541222] [<ffffffff81a1ea00>] ? gs_change+0x13/0x13
[ 1186.541224] ---[ end trace 6fa3da5fd65420b1 ]---
[ 1186.541076] WARNING: at fs/btrfs/extent-tree.c:4617
__btrfs_free_extent+0x60d/0x6c0 [btrfs]()
[ 1186.541079] Hardware name: Santa Rosa platform
[ 1186.541080] Modules linked in: btrfs aoe
[ 1186.541084] Pid: 5007, comm: btrfs-transacti Tainted: G W
3.1.0-default+ #64
[ 1186.541086] Call Trace:
[ 1186.541089] [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0
[ 1186.541093] [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20
[ 1186.541101] [<ffffffffa0024b2d>] __btrfs_free_extent+0x60d/0x6c0
[btrfs]
[ 1186.541105] [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.541114] [<ffffffffa0028949>] run_clustered_refs+0x399/0x850
[btrfs]
[ 1186.541126] [<ffffffffa0079800>] ? btrfs_find_ref_cluster+0xb0/0x1a0
[btrfs]
[ 1186.541136] [<ffffffffa0028ec8>] btrfs_run_delayed_refs+0xc8/0x220
[btrfs]
[ 1186.541139] [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.541149] [<ffffffffa0029178>]
btrfs_write_dirty_block_groups+0x158/0x540 [btrfs]
[ 1186.541160] [<ffffffffa0038ee5>] commit_cowonly_roots+0x115/0x1e0
[btrfs]
[ 1186.541172] [<ffffffffa0039ee7>] btrfs_commit_transaction+0x477/0x8f0
[btrfs]
[ 1186.541183] [<ffffffffa00391a9>] ? join_transaction+0x69/0x2b0 [btrfs]
[ 1186.541186] [<ffffffff8107d480>] ? wake_up_bit+0x40/0x40
[ 1186.541196] [<ffffffffa0032a1b>] transaction_kthread+0x28b/0x2a0
[btrfs]
[ 1186.541207] [<ffffffffa0032790>] ? btree_readpage+0x30/0x30 [btrfs]
[ 1186.541210] [<ffffffff8107cf16>] kthread+0xa6/0xb0
[ 1186.541213] [<ffffffff81a1ea04>] kernel_thread_helper+0x4/0x10
[ 1186.541216] [<ffffffff81a15334>] ? retint_restore_args+0x13/0x13
[ 1186.541219] [<ffffffff8107ce70>] ? __init_kthread_worker+0x70/0x70
[ 1186.541222] [<ffffffff81a1ea00>] ? gs_change+0x13/0x13
[ 1186.541224] ---[ end trace 6fa3da5fd65420b1 ]---
4615 } else {
4616 btrfs_print_leaf(extent_root, path->nodes[0]);
4617 WARN_ON(1);
4618 printk(KERN_ERR "btrfs unable to find ref byte nr %llu
"
4619 "parent %llu root %llu owner %llu offset
%llu\n",
4620 (unsigned long long)bytenr,
4621 (unsigned long long)parent,
4622 (unsigned long long)root_objectid,
4623 (unsigned long long)owner_objectid,
4624 (unsigned long long)owner_offset);
4625 }
[ 1186.541227] btrfs unable to find ref byte nr 428474368 parent 0 root 7 owner
0 offset 0
[ 1186.541234] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 1186.541237] IP: [<ffffffffa005b881>]
map_private_extent_buffer+0x21/0x1f0 [btrfs]
[ 1186.541250] PGD 51ece067 PUD 6425d067 PMD 0
[ 1186.541253] Oops: 0000 [#1] SMP
[ 1186.541257] CPU 0
[ 1186.541258] Modules linked in: btrfs aoe
[ 1186.541261]
[ 1186.541263] Pid: 5007, comm: btrfs-transacti Tainted: G W
3.1.0-default+ #64 Intel Corporation Santa Rosa platform/Matanzas
[ 1186.541268] RIP: 0010:[<ffffffffa005b881>] [<ffffffffa005b881>]
map_private_extent_buffer+0x21/0x1f0 [btrfs]
[ 1186.541281] RSP: 0018:ffff8800795d1960 EFLAGS: 00010286
[ 1186.541283] RAX: 0000000000000000 RBX: 0000000000000065 RCX: ffff8800795d19d0
[ 1186.541285] RDX: 0000000000000004 RSI: 000000000000007a RDI: 0000000000000000
[ 1186.541288] RBP: ffff8800795d19b0 R08: ffff8800795d19c8 R09: ffff8800795d19c0
[ 1186.541290] R10: 0000000000000001 R11: 0000000000000001 R12: 000000000000007a
[ 1186.541292] R13: 0000000000000000 R14: 0000000000000065 R15: 0000000000000000
[ 1186.541295] FS: 0000000000000000(0000) GS:ffff88007c000000(0000)
knlGS:0000000000000000
[ 1186.541297] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1186.541300] CR2: 0000000000000000 CR3: 000000006a578000 CR4: 00000000000006f0
[ 1186.541302] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1186.541304] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1186.541307] Process btrfs-transacti (pid: 5007, threadinfo ffff8800795d0000,
task ffff88007a00c880)
[ 1186.541309] Stack:
[ 1186.541310] ffff8800795d1970 00ffffff00000003 ffff8800795d19b0
ffff880078da6520
[ 1186.541314] 0000000000000000 0000000000000065 000000000000007a
0000000000000000
[ 1186.541318] 0000000000000065 0000000000000000 ffff8800795d1a00
ffffffffa0050dfc
[ 1186.541322] Call Trace:
[ 1186.541335] [<ffffffffa0050dfc>] btrfs_item_size+0x3c/0x90 [btrfs]
[ 1186.541344] [<ffffffffa0024755>] __btrfs_free_extent+0x235/0x6c0
[btrfs]
[ 1186.541348] [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.541357] [<ffffffffa0028949>] run_clustered_refs+0x399/0x850
[btrfs]
[ 1186.541369] [<ffffffffa0079800>] ? btrfs_find_ref_cluster+0xb0/0x1a0
[btrfs]
[ 1186.541378] [<ffffffffa0028ec8>] btrfs_run_delayed_refs+0xc8/0x220
[btrfs]
[ 1186.541382] [<ffffffff813628be>] ? do_raw_spin_unlock+0x5e/0xb0
[ 1186.541391] [<ffffffffa0029178>]
btrfs_write_dirty_block_groups+0x158/0x540 [btrfs]
[ 1186.541402] [<ffffffffa0038ee5>] commit_cowonly_roots+0x115/0x1e0
[btrfs]
[ 1186.541414] [<ffffffffa0039ee7>] btrfs_commit_transaction+0x477/0x8f0
[btrfs]
[ 1186.541425] [<ffffffffa00391a9>] ? join_transaction+0x69/0x2b0 [btrfs]
[ 1186.541428] [<ffffffff8107d480>] ? wake_up_bit+0x40/0x40
[ 1186.541439] [<ffffffffa0032a1b>] transaction_kthread+0x28b/0x2a0
[btrfs]
[ 1186.541449] [<ffffffffa0032790>] ? btree_readpage+0x30/0x30 [btrfs]
[ 1186.541452] [<ffffffff8107cf16>] kthread+0xa6/0xb0
[ 1186.541456] [<ffffffff81a1ea04>] kernel_thread_helper+0x4/0x10
[ 1186.541459] [<ffffffff81a15334>] ? retint_restore_args+0x13/0x13
[ 1186.541462] [<ffffffff8107ce70>] ? __init_kthread_worker+0x70/0x70
[ 1186.541464] [<ffffffff81a1ea00>] ? gs_change+0x13/0x13
[ 1186.541466] Code: 55 90 e9 b6 fc ff ff 0f 1f 00 55 48 89 e5 48 83 ec 50 48 89
5d d8 4c 89 65 e0 4c 89 6d e8 4c 89 75 f0 4c 89 7d f8 66 66 66 66 90 <4c>
8b 37 49 89 cd 4c 89 cb 41 81 e6 ff 0f 00 00 4a 8d 04 36 48
[ 1186.541493] RIP [<ffffffffa005b881>]
map_private_extent_buffer+0x21/0x1f0 [btrfs]
[ 1186.541506] RSP <ffff8800795d1960>
[ 1186.541507] CR2: 0000000000000000
[ 1187.258581] ---[ end trace 6fa3da5fd65420b2 ]---
david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Sterba
2011-Nov-01 16:16 UTC
Re: BUG at fs/btrfs/tree-log.c:3106 (Re: new integration-danger branch pushed out (kernel))
On Tue, Nov 01, 2011 at 06:56:50AM -0400, Chris Mason wrote:> On Tue, Nov 01, 2011 at 11:36:37AM +0100, David Sterba wrote: > > xfstests/214 > > > > [ 3142.654774] ------------[ cut here ]------------ > > [ 3142.656017] kernel BUG at fs/btrfs/tree-log.c:3106! > > What kind of hardware are you running this on? I''m passing 214 here.this is some old piece of hw, intel 2x 2.2Ghz CPU, 2GB memory, ICH8, SATA controller is 82801HBM/HEM. partition setup: SCRATCH Label: none uuid: b3aabfae-69f6-4b9b-9dc0-e1ec3472183c Total devices 1 FS bytes used 11.32MB devid 1 size 104.00MB used 104.00MB path /dev/sda9 TEST Label: none uuid: d0e2fc5f-8a72-4c54-bee3-3c8ae1766ade Total devices 4 FS bytes used 15.16MB devid 4 size 10.00GB used 1.01GB path /dev/sda8 devid 3 size 10.00GB used 1.01GB path /dev/sda7 devid 2 size 10.00GB used 2.00GB path /dev/sda6 devid 1 size 10.00GB used 2.02GB path /dev/sda5 mkfs was default. the second box, which reproduced this same BUG, is 8 CPU AMD, partition setup is: Label: none uuid: 686f0422-2bc5-4265-a4a7-f17f21cdcfd0 Total devices 1 FS bytes used 11.31MB devid 1 size 104.00MB used 104.00MB path /dev/sda9 Label: none uuid: c17552f9-4727-411d-9b75-5d84a1c5ba66 Total devices 4 FS bytes used 13.18MB devid 4 size 30.00GB used 30.00GB path /dev/sda8 devid 3 size 30.00GB used 30.00GB path /dev/sda7 devid 2 size 30.00GB used 30.00GB path /dev/sda6 devid 1 size 30.00GB used 30.00GB path /dev/sda5 and the crashdump is [ 5326.176937] ------------[ cut here ]------------ [ 5326.180791] kernel BUG at fs/btrfs/tree-log.c:3106! [ 5326.180791] invalid opcode: 0000 [#1] SMP [ 5326.180791] CPU 5 [ 5326.180791] Modules linked in: btrfs zlib_deflate crc32c libcrc32c edd nfs lockd fscache auth_rpcgss nfs_acl sunrpc af_packet bridge ipv6 stp llc cpufreq_conservative cpufreq_userspace cpufreq_powersave powernow_k8 mperf microcode fuse loop dm_mod kvm_amd kvm tpm_infineon tg3 amd64_edac_mod edac_core shpchp edac_mce_amd i2c_piix4 i2c_core pcspkr tpm_tis tpm tpm_bios pci_hotplug sg sr_mod k10temp cdrom rtc_cmos button mptctl ext3 jbd mbcache ohci_hcd ehci_hcd usbcore sd_mod crc_t10dif fan thermal processor thermal_sys hwmon ide_pci_generic serverworks ide_core ata_generic sata_svw pata_serverworks libata mptsas mptscsih mptbase scsi_transport_sas scsi_mod [last unloaded: floppy] [ 5326.180791] [ 5326.180791] Pid: 17588, comm: xfs_io Tainted: G W 3.1.0-default+ #3 [ 5326.180791] RIP: 0010:[<ffffffffa05e0504>] [<ffffffffa05e0504>] btrfs_log_inode+0x4c4/0x680 [btrfs] [ 5326.180791] RSP: 0018:ffff880054857d18 EFLAGS: 00010282 [ 5326.180791] RAX: 00000000ffffffef RBX: 0000000000000353 RCX: ffff88011d703300 [ 5326.180791] RDX: 000000000000002e RSI: 0000000000000001 RDI: 0000000000000286 [ 5326.180791] RBP: ffff880054857e38 R08: ffff880054857aa8 R09: 0000000000001000 [ 5326.180791] R10: 00000000000000da R11: 0000000000000000 R12: ffff8801297eb400 [ 5326.180791] R13: 0000000000000003 R14: ffff880024d781e0 R15: ffff88011861f1d8 [ 5326.180791] FS: 00007f2c3354e700(0000) GS:ffff88012fc80000(0000) knlGS:0000000000000000 [ 5326.180791] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 5326.180791] CR2: 00007f4d712f8c30 CR3: 0000000127a31000 CR4: 00000000000006e0 [ 5326.180791] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 5326.180791] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 5326.180791] Process xfs_io (pid: 17588, threadinfo ffff880054856000, task ffff880076a26300) [ 5326.180791] Stack: [ 5326.180791] ffff880000000000 0007ffffffffffff ffff880054857d78 00000000810e85e0 [ 5326.180791] ffff88007ba7f000 ffff8801101e8108 0000000000000000 0000000000000c23 [ 5326.180791] 0000000000000c23 ffff88011861f0e0 ffff880110030ac0 0000001c00000000 [ 5326.180791] Call Trace: [ 5326.180791] [<ffffffff810e9db3>] ? filemap_fdatawait_range+0x93/0x150 [ 5326.180791] [<ffffffffa05e080c>] btrfs_log_inode_parent+0x14c/0x2d0 [btrfs] [ 5326.180791] [<ffffffffa05ac55f>] ? join_transaction+0x1f/0x250 [btrfs] [ 5326.180791] [<ffffffffa05e0a44>] btrfs_log_dentry_safe+0x44/0x70 [btrfs] [ 5326.180791] [<ffffffffa05badbf>] btrfs_sync_file+0x16f/0x1c0 [btrfs] [ 5326.180791] [<ffffffff81172283>] vfs_fsync_range+0x23/0x30 [ 5326.180791] [<ffffffff811722a7>] vfs_fsync+0x17/0x20 [ 5326.180791] [<ffffffff811724b5>] do_fsync+0x35/0x60 [ 5326.180791] [<ffffffff8117250b>] sys_fsync+0xb/0x10 [ 5326.180791] [<ffffffff814232d2>] system_call_fastpath+0x16/0x1b [ 5326.180791] Code: 3c ff ff ff 45 89 e9 48 8b bd 08 ff ff ff 4c 89 f1 4c 89 fe 89 14 24 48 8b 95 30 ff ff ff e8 e4 f6 ff ff 85 c0 0f 84 c5 fc ff ff <0f> 0b eb fe 0f 1f 84 00 00 00 00 00 45 85 ed 74 33 8b 85 fc fe [ 5326.180791] RIP [<ffffffffa05e0504>] btrfs_log_inode+0x4c4/0x680 [btrfs] [ 5326.180791] RSP <ffff880054857d18> [ 5326.482211] ---[ end trace 0a323c63265b6de4 ]--- [while writing this mail, testbox1 just tripped over the BUG again] In both cases, the xfstests suite was run on clean mkfs and from test 001 on. I see that process "rm -f /mnt/sda5/ouch2" is stuck at $ cat /proc/17594/stack [<ffffffff81152ae1>] vfs_unlink+0x61/0x120 [<ffffffff81156723>] do_unlinkat+0x1d3/0x1e0 [<ffffffff811568ad>] sys_unlinkat+0x1d/0x40 [<ffffffff814232d2>] system_call_fastpath+0x16/0x1b [<ffffffffffffffff>] 0xffffffffffffffff So, bug is reproducible quite reliably. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Sterba
2011-Nov-01 16:39 UTC
Re: BUG at fs/btrfs/tree-log.c:3106 (Re: new integration-danger branch pushed out (kernel))
On Tue, Nov 01, 2011 at 11:36:37AM +0100, David Sterba wrote:> xfstests/214 > > [ 3142.654774] ------------[ cut here ]------------ > [ 3142.656017] kernel BUG at fs/btrfs/tree-log.c:3106! > [ 3142.656017] invalid opcode: 0000 [#1] SMP > [ 3142.656017] CPU 0 > [ 3142.656017] Modules linked in: loop btrfs aoe > [ 3142.656017] > [ 3142.656017] Pid: 27328, comm: xfs_io Tainted: G W 3.1.0-default+ #64 Intel Corporation Santa Rosa platform/Matanzas > [ 3142.656017] RIP: 0010:[<ffffffffa006fe74>] [<ffffffffa006fe74>] btrfs_log_inode+0x554/0x600 [btrfs] > [ 3142.656017] RSP: 0018:ffff88005c801d58 EFLAGS: 00010282 > [ 3142.656017] RAX: 00000000ffffffef RBX: ffff88003ef39e20 RCX: 0000000000000006 > [ 3142.656017] RDX: 0000000000000001 RSI: ffff8800643aa170 RDI: 0000000000000286 > [ 3142.656017] RBP: ffff88005c801e48 R08: 0000000000000001 R09: 0000000000000001 > [ 3142.656017] R10: 0000000000000001 R11: 0000000000000002 R12: ffff88003405fe70 > [ 3142.656017] R13: ffff88005c801db8 R14: 0000000000000003 R15: ffff8800340604b0 > [ 3142.656017] FS: 00007f7034667700(0000) GS:ffff88007dc00000(0000) knlGS:0000000000000000 > [ 3142.656017] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 3142.656017] CR2: 00000000006b1fb0 CR3: 00000000778df000 CR4: 00000000000006f0 > [ 3142.656017] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 3142.656017] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 3142.656017] Process xfs_io (pid: 27328, threadinfo ffff88005c800000, task ffff8800643a9ac0) > [ 3142.656017] Stack: > [ 3142.656017] 0000000000000000 0000000000000000 ffff8800340602b0 ffff880072efe000 > [ 3142.656017] 0000000000000000 00000000000004c8 000000005c801dd8 ffff8800340604b0 > [ 3142.656017] ffff88003ef39eb0 ffff88000dfb4420 0000000000000019 0000000000000308 > [ 3142.656017] Call Trace: > [ 3142.656017] [<ffffffffa0070d28>] btrfs_log_inode_parent+0x198/0x480 [btrfs] > [ 3142.656017] [<ffffffff8115941c>] ? dget_parent+0x1c/0xd0 > [ 3142.656017] [<ffffffffa0071059>] btrfs_log_dentry_safe+0x49/0x70 [btrfs] > [ 3142.656017] [<ffffffffa0049406>] btrfs_sync_file+0x146/0x1d0 [btrfs] > [ 3142.656017] [<ffffffff81143e80>] ? fget_raw+0x210/0x210 > [ 3142.656017] [<ffffffff81171029>] do_fsync+0x59/0x80 > [ 3142.656017] [<ffffffff81171340>] sys_fsync+0x10/0x20 > [ 3142.656017] [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b > [ 3142.656017] Code: 60 ff ff ff 45 89 f1 48 8b bd 58 ff ff ff 4c 89 e1 4c 89 fe 89 14 24 48 8b 95 50 ff ff ff e8 44 cf ff ff 85 c0 0f 84 04 fe ff ff <0f> 0b 48 89 df e8 f2 62 fa ff 48 8b bd 50 ff ff ff e8 e6 62 fa > [ 3142.656017] RIP [<ffffffffa006fe74>] btrfs_log_inode+0x554/0x600 [btrfs] > [ 3142.656017] RSP <ffff88005c801d58> > [ 3142.995743] ---[ end trace 81d2bc6c70d7ca63 ]---for the record, exactly same crash at xfstets/256 (run from 215- on), with "rm -f /mnt/a1/25365.falloc" stuck (D) at vfs_unlink david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Mason
2011-Nov-02 00:56 UTC
Re: Warnings (was: Re: new integration-danger branch pushed out (kernel))
On Tue, Nov 01, 2011 at 11:11:10AM +0100, David Sterba wrote:> Hi, > > On Mon, Oct 31, 2011 at 10:49:57PM -0400, Chris Mason wrote: > > I''ve pushed out a new integration branch, but it is not for general use. > > Thank you! > > xfstests/083 and 089 cause the following warnings. I''ve seen them before when > testing josef/for-chris and josef/master branches (reported on irc).Ok, just a status update on my end. Josef and I have the block group warnings fixed. The tree log crash is also explained, the eexist oops comes when you''re using the inode_cache code (hopefully you are?). I have one test fix for this but it still has a few wrinkles that I''ll have to sort out in the morning. -chris> > [ 1149.108088] ------------[ cut here ]------------ > [ 1149.114384] WARNING: at fs/btrfs/extent-tree.c:3932 btrfs_free_block_groups+0x304/0x320 [btrfs]() > [ 1149.124928] Hardware name: Santa Rosa platform > [ 1149.124931] Modules linked in: loop btrfs aoe > [ 1149.124938] Pid: 23991, comm: umount Not tainted 3.1.0-default+ #64 > [ 1149.124941] Call Trace: > [ 1149.124950] [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0 > [ 1149.124953] [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20 > [ 1149.124973] [<ffffffffa002bba4>] btrfs_free_block_groups+0x304/0x320 [btrfs] > [ 1149.124985] [<ffffffffa0036ab9>] close_ctree+0x1e9/0x390 [btrfs] > [ 1149.124991] [<ffffffff8115e2df>] ? dispose_list+0x4f/0x60 > [ 1149.124999] [<ffffffffa00108dd>] btrfs_put_super+0x1d/0x30 [btrfs] > [ 1149.125003] [<ffffffff81145202>] generic_shutdown_super+0x62/0xe0 > [ 1149.125006] [<ffffffff81145316>] kill_anon_super+0x16/0x30 > [ 1149.125009] [<ffffffff811461a2>] ? deactivate_super+0x42/0x70 > [ 1149.125012] [<ffffffff811456dd>] deactivate_locked_super+0x3d/0xa0 > [ 1149.125015] [<ffffffff811461aa>] deactivate_super+0x4a/0x70 > [ 1149.125019] [<ffffffff81162972>] mntput_no_expire+0xa2/0xf0 > [ 1149.125022] [<ffffffff811636df>] sys_umount+0x6f/0x390 > [ 1149.125027] [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b > [ 1149.125030] ---[ end trace 81d2bc6c70d7ca56 ]--- > [ 1149.125032] ------------[ cut here ]------------ > [ 1149.125041] WARNING: at fs/btrfs/extent-tree.c:3933 btrfs_free_block_groups+0x2ee/0x320 [btrfs]() > [ 1149.125044] Hardware name: Santa Rosa platform > [ 1149.125045] Modules linked in: loop btrfs aoe > [ 1149.125049] Pid: 23991, comm: umount Tainted: G W 3.1.0-default+ #64 > [ 1149.125051] Call Trace: > [ 1149.125054] [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0 > [ 1149.125057] [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20 > [ 1149.125067] [<ffffffffa002bb8e>] btrfs_free_block_groups+0x2ee/0x320 [btrfs] > [ 1149.125078] [<ffffffffa0036ab9>] close_ctree+0x1e9/0x390 [btrfs] > [ 1149.125081] [<ffffffff8115e2df>] ? dispose_list+0x4f/0x60 > [ 1149.125089] [<ffffffffa00108dd>] btrfs_put_super+0x1d/0x30 [btrfs] > [ 1149.125092] [<ffffffff81145202>] generic_shutdown_super+0x62/0xe0 > [ 1149.125096] [<ffffffff81145316>] kill_anon_super+0x16/0x30 > [ 1149.125099] [<ffffffff811461a2>] ? deactivate_super+0x42/0x70 > [ 1149.125102] [<ffffffff811456dd>] deactivate_locked_super+0x3d/0xa0 > [ 1149.125105] [<ffffffff811461aa>] deactivate_super+0x4a/0x70 > [ 1149.125108] [<ffffffff81162972>] mntput_no_expire+0xa2/0xf0 > [ 1149.125111] [<ffffffff811636df>] sys_umount+0x6f/0x390 > [ 1149.125115] [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b > [ 1149.125117] ---[ end trace 81d2bc6c70d7ca57 ]--- > > The code in question: > > 3927 static void release_global_block_rsv(struct btrfs_fs_info *fs_info) > 3928 { > 3929 block_rsv_release_bytes(&fs_info->global_block_rsv, NULL, (u64)-1); > 3930 WARN_ON(fs_info->delalloc_block_rsv.size > 0); > 3931 WARN_ON(fs_info->delalloc_block_rsv.reserved > 0); > > 3932 WARN_ON(fs_info->trans_block_rsv.size > 0); > 3933 WARN_ON(fs_info->trans_block_rsv.reserved > 0); > > 3934 WARN_ON(fs_info->chunk_block_rsv.size > 0); > 3935 WARN_ON(fs_info->chunk_block_rsv.reserved > 0); > 3936 } > > > [ 1149.125119] ------------[ cut here ]------------ > [ 1149.125128] WARNING: at fs/btrfs/extent-tree.c:7090 btrfs_free_block_groups+0x23b/0x320 [btrfs]() > [ 1149.125130] Hardware name: Santa Rosa platform > [ 1149.125131] Modules linked in: loop btrfs aoe > [ 1149.125135] Pid: 23991, comm: umount Tainted: G W 3.1.0-default+ #64 > [ 1149.125137] Call Trace: > [ 1149.125140] [<ffffffff81057fdf>] warn_slowpath_common+0x7f/0xc0 > [ 1149.125143] [<ffffffff8105803a>] warn_slowpath_null+0x1a/0x20 > [ 1149.125153] [<ffffffffa002badb>] btrfs_free_block_groups+0x23b/0x320 [btrfs] > [ 1149.125164] [<ffffffffa0036ab9>] close_ctree+0x1e9/0x390 [btrfs] > [ 1149.125167] [<ffffffff8115e2df>] ? dispose_list+0x4f/0x60 > [ 1149.125175] [<ffffffffa00108dd>] btrfs_put_super+0x1d/0x30 [btrfs] > [ 1149.125178] [<ffffffff81145202>] generic_shutdown_super+0x62/0xe0 > [ 1149.125181] [<ffffffff81145316>] kill_anon_super+0x16/0x30 > [ 1149.125184] [<ffffffff811461a2>] ? deactivate_super+0x42/0x70 > [ 1149.125187] [<ffffffff811456dd>] deactivate_locked_super+0x3d/0xa0 > [ 1149.125191] [<ffffffff811461aa>] deactivate_super+0x4a/0x70 > [ 1149.125194] [<ffffffff81162972>] mntput_no_expire+0xa2/0xf0 > [ 1149.125197] [<ffffffff811636df>] sys_umount+0x6f/0x390 > [ 1149.125200] [<ffffffff81a1d782>] system_call_fastpath+0x16/0x1b > [ 1149.125202] ---[ end trace 81d2bc6c70d7ca58 ]--- > [ 1149.125206] space_info 5 has 4931584 free, is full > [ 1149.125208] space_info total=48234496, used=43302912, pinned=0, reserved=0, may_use=294912, readonly=0 > > > 7028 int btrfs_free_block_groups(struct btrfs_fs_info *info) > ... > 7083 while(!list_empty(&info->space_info)) { > 7084 space_info = list_entry(info->space_info.next, > 7085 struct btrfs_space_info, > 7086 list); > 7087 if (space_info->bytes_pinned > 0 || > 7088 space_info->bytes_reserved > 0 || > 7089 space_info->bytes_may_use > 0) { > > 7090 WARN_ON(1); > > 7091 dump_space_info(space_info, 0, 0); > 7092 } > 7093 list_del(&space_info->list); > 7094 kfree(space_info); > 7095 } > 7096 return 0; > 7097 } > > > david-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/01/2011 06:55 PM, Chris Mason wrote:> On Tue, Nov 01, 2011 at 05:22:20PM +0800, Liu Bo wrote: >> Hi, >> >> On 11/01/2011 10:49 AM, Chris Mason wrote: >>> Hi everyone, >>> >>> I''ve pushed out a new integration branch, but it is not for general use. >>> >>> I''m still going through and hammering on the new logging code code to >>> make sure it is properly backwards compatible with older kernels and >>> that it hasn''t introduced any new bugs. >>> >>> *** Please do not use this code on anything other than test filesystems that >>> can easily be reformatted. *** >>> >>> In testing the new sub-transid logging code, I''ve spent a lot of time >>> hunting logging bugs, and writing new tests to try and make sure the >>> logging code is working correctly in general. Between that and some new >>> tests from Arne, I''ve had to make some pretty big changes to the code. >>> >> I''m giving a hard read on the new code, and I notice a slight change: > > Thanks a lot for reading it carefully. > >> @@ -3006,14 +3179,11 @@ out: >> static int inode_in_log(struct btrfs_trans_handle *trans, >> struct inode *inode) >> { >> - struct btrfs_root *root = BTRFS_I(inode)->root; >> int ret = 0; >> >> - mutex_lock(&root->log_mutex); >> - if (BTRFS_I(inode)->logged_trans == trans->transid && >> - BTRFS_I(inode)->last_sub_trans <= root->last_log_commit) >> + if (BTRFS_I(inode)->logged_trans >= trans->transaction->transid && >> + BTRFS_I(inode)->last_trans < BTRFS_I(inode)->logged_trans) >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> ret = 1; >> - mutex_unlock(&root->log_mutex); >> return ret; >> } >> >> since we''ve moved the "sub_transid++" update to btrfs_sync_log(), the ending of log, >> say there is a case like this: >> >> transaction ------------------------------------------ start >> | >> sub_trans A | --- start >> | >> | --- modify inode X, and set X''s last_trans to sub_transid >> | | >> | | --- fsync inode X, and set X''s logged_trans to sub_transid >> | | >> | | --- in btrfs_sync_log(), sub_transid++ >> | | >> \|/ | --- end >> | >> sub_trans A+1 | --- start >> | >> | --- no change to inode X >> | >> | --- fsync inode X >> | >> | --- in inode_in_log(), X''s last_trans is equal to X''s logged_trans, >> unchanged X is just in the log, but we need to log X again. >> >> ...... ...... >> >> transaction ------------------------------------------ end >> >> we do not want this, does we? Or am I missing something? > > Correct, this is less optimal. I was finding races where the transid > increasing at the start of the log trans would lead to one process > missing file and directory updates done by another process. > > So I made the patch slightly more conservative. We''re still logging > about 75% less than we used to in every workload I''ve tried, but we can > definitely refine this in future commits. >Ok, got it, thanks for the explanation.> Along the way I fixed an old bug in directory logging that meant we > almost always force a full commit for directory fsyncs. The fix means > we use the directory log more often now, which is faster in some cases > and slower in others. >I know them, one from drop_objectid_items() and the other from check_parent_dirs_for_sync(), both have been fixed in the new code. thanks, liubo> It also means a bug with delayed metadata insertion triggers more easily > during log replay (we need to flush the delayed ops during log replay). > The bug was hidden before because the directory log wasn''t being used > much. > > -chris > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Sterba
2011-Nov-02 13:06 UTC
Re: Warnings (was: Re: new integration-danger branch pushed out (kernel))
On Tue, Nov 01, 2011 at 08:56:15PM -0400, Chris Mason wrote:> > xfstests/083 and 089 cause the following warnings. I''ve seen them before when > > testing josef/for-chris and josef/master branches (reported on irc). > > Ok, just a status update on my end. Josef and I have the block group > warnings fixed.I confirm the warnings do not show anymore with the "Btrfs: release metadata from global reserve if we have to fallback for unlink" patch.> The tree log crash is also explained, the eexist oops > comes when you''re using the inode_cache code (hopefully you are?).yes, MOUNT_OPTIONS=''-o compress=lzo,discard,inode_cache,space_cache,autodefrag''> I have one test fix for this but it still has a few wrinkles that I''ll > have to sort out in the morning.Great, I''m ready to test it. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
David Sterba
2011-Nov-02 17:06 UTC
All green (Re: new integration-danger branch pushed out (kernel))
Hi, all reported issues are fixed with the updated branch, thanks! david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
This one happened again, exactly same sequence of warnings and the crash at the end (same stack traces). It was in integration-scrub branch, ie. with all fixes on top. (I have captured sysrq-w, /proc/pid/stack of all processes and have the dmesg logs if anybody is interested.) david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 03, 2011 at 12:02:31AM +0100, David Sterba wrote:> This one happened again, exactly same sequence of warnings and the crash > at the end (same stack traces). It was in integration-scrub branch, ie. > with all fixes on top. > > (I have captured sysrq-w, /proc/pid/stack of all processes and have the > dmesg logs if anybody is interested.)Yes, I''d like to see the logs. We need to figure out if we just failed with enospc in a critical spot or if there are other bigger problems. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 2, 2011 at 6:40 PM, Chris Mason <chris.mason@oracle.com> wrote:> On Thu, Nov 03, 2011 at 12:02:31AM +0100, David Sterba wrote: >> This one happened again, exactly same sequence of warnings and the crash >> at the end (same stack traces). It was in integration-scrub branch, ie. >> with all fixes on top. >> >> (I have captured sysrq-w, /proc/pid/stack of all processes and have the >> dmesg logs if anybody is interested.) > > Yes, I''d like to see the logs. We need to figure out if we just failed > with enospc in a critical spot or if there are other bigger problems. >I''m seeing similar warnings while testing the integration-scrub branch. I''m testing on a 16-GB partition that is less than 20% full when I''m seeing the warning. Let me know if you''re still working on this issue, and I''ll try to isolate the command that is running. [ 8631.183234] device fsid aff24946-5596-4c19-a6c4-81809ae6bd94 devid 1 transid 7 /dev/sdb6 [ 8631.183483] btrfs: disk space caching is enabled [ 8712.675332] btrfs: block rsv returned -28 [ 8712.675334] ------------[ cut here ]------------ [ 8712.675362] WARNING: at fs/btrfs/extent-tree.c:5837 btrfs_alloc_free_block+0x3e9/0x400 [btrfs]() [ 8712.675364] Hardware name: P35-DS3L [ 8712.675365] Modules linked in: ipv6 snd_seq_midi snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss lgdt330x cx88_dvb cx88_vp3054_i2c videobuf_dvb dvb_core rc_hauppauge tuner_simple tuner_types tda9887 tda8290 tuner nvidia(P) ir_lirc_codec lirc_dev ir_mce_kbd_decoder cx88_alsa cx8800 ir_sony_decoder ir_jvc_decoder ir_rc6_decoder cx8802 cx88xx snd_ens1371 ir_rc5_decoder ir_nec_decoder gameport snd_rawmidi snd_seq_device rc_core i2c_algo_bit snd_ac97_codec videobuf_dma_sg tveeprom v4l2_common videodev media v4l2_compat_ioctl32 videobuf_core btcx_risc iTCO_wdt iTCO_vendor_support intel_agp intel_gtt ac97_bus snd_pcm snd_timer i2c_i801 snd i2c_core snd_page_alloc ppdev parport_pc parport tpm_tis tpm r8169 tpm_bios sr_mod pcspkr iscsi_tcp libiscsi_tcp libiscsi fuse nfs nfs_acl auth_rpcgss lockd sunrpc btrfs zlib_deflate sl811_hcd ohci_hcd uhci_hcd ehci_hcd [ 8712.675409] Pid: 7917, comm: btrfs-transacti Tainted: P 3.1.0-integration-scrub+ #1 [ 8712.675411] Call Trace: [ 8712.675417] [<ffffffff81046e8f>] warn_slowpath_common+0x7f/0xc0 [ 8712.675420] [<ffffffff81046eea>] warn_slowpath_null+0x1a/0x20 [ 8712.675428] [<ffffffffa004a2e9>] btrfs_alloc_free_block+0x3e9/0x400 [btrfs] [ 8712.675435] [<ffffffffa003b621>] ? btrfs_leaf_free_space+0x61/0xb0 [btrfs] [ 8712.675442] [<ffffffffa0039069>] __btrfs_cow_block+0x119/0x560 [btrfs] [ 8712.675451] [<ffffffffa0054070>] ? btrfs_buffer_uptodate+0x50/0x70 [btrfs] [ 8712.675458] [<ffffffffa0039669>] btrfs_cow_block+0x1b9/0x2f0 [btrfs] [ 8712.675465] [<ffffffffa003d640>] btrfs_search_slot+0x5c0/0xa90 [btrfs] [ 8712.675473] [<ffffffffa0048b49>] btrfs_write_dirty_block_groups+0xd9/0x530 [btrfs] [ 8712.675481] [<ffffffffa0048952>] ? btrfs_run_delayed_refs+0xf2/0x210 [btrfs] [ 8712.675490] [<ffffffffa0057475>] commit_cowonly_roots+0x115/0x1e0 [btrfs] [ 8712.675499] [<ffffffffa0058a74>] btrfs_commit_transaction+0x404/0x8a0 [btrfs] [ 8712.675508] [<ffffffffa0057e31>] ? join_transaction.clone.24+0x21/0x240 [btrfs] [ 8712.675511] [<ffffffff81068e30>] ? wake_up_bit+0x40/0x40 [ 8712.675520] [<ffffffffa0051ee3>] transaction_kthread+0x263/0x280 [btrfs] [ 8712.675528] [<ffffffffa0051c80>] ? btrfs_congested_fn+0xb0/0xb0 [btrfs] [ 8712.675536] [<ffffffffa0051c80>] ? btrfs_congested_fn+0xb0/0xb0 [btrfs] [ 8712.675539] [<ffffffff810688a6>] kthread+0x96/0xa0 [ 8712.675542] [<ffffffff816d3b54>] kernel_thread_helper+0x4/0x10 [ 8712.675545] [<ffffffff81068810>] ? kthread_worker_fn+0x1a0/0x1a0 [ 8712.675547] [<ffffffff816d3b50>] ? gs_change+0xb/0xb [ 8712.675549] ---[ end trace 234618ad5fea81a4 ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html