Skip to contentSkip to conversation

new integration-danger branch pushed out (kernel)

DISCUSSION Chris Mason 4 participants 17 messages Nov 1, 2011 – Nov 4, 2011 Btrfs file system

lore
Share & tools
lore

Chris Mason

author
#0 lore raw

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

#1 lore raw

Hi,

Quoted 8 lines · Chris Mason

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.

Quoted 8 lines

*** 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

Quoted 19 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#2 lore raw
Quoted 14 lines · Liu Bo

Hi,

Quoted 11 lines · Chris Mason

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. ***

Quoted 7 lines
Quoted 5 lines

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.

Quoted 40 lines
(quoted diff) +2 -5
@@ -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,
Quoted 7 lines

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

#3 lore raw
Quoted 76 lines · Chris Mason
Quoted 14 lines · Liu Bo

Hi,

Quoted 11 lines · Chris Mason

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. ***

Quoted 6 lines
Quoted 5 lines

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.

Quoted 40 lines
(quoted diff) +2 -5
@@ -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,
Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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

Quoted 12 lines

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw

Warnings (was: Re: new integration-danger branch pushed out (kernel))

In reply to Chris Mason

Hi,

Quoted 1 line · Chris Mason

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

author
#5 lore raw

Re: Warnings (was: Re: new integration-danger branch pushed out (kernel))

Quoted 9 lines · David Sterba

Hi,

Quoted 1 line · Chris Mason

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

Quoted 107 lines
[ 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

#6 lore raw

Re: Warnings (was: Re: new integration-danger branch pushed out (kernel))

Quoted 5 lines · Chris Mason
Quoted 2 lines

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.

Quoted 2 lines

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'

Quoted 2 lines

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

#7 lore raw

Warnings: destroy inode (was: new integration-danger branch pushed out (kernel))

In reply to Chris Mason

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.bad 2011-11-01 11:20:53.000000000 +0100 renamed from 209.out 2011-02-11 11:42:31.000000000 +0100 +1 -1
@@ -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

#8 lore raw

BUG at fs/btrfs/tree-log.c:3106 (Re: new integration-danger branch pushed out (kernel))

In reply to Chris Mason

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 <[email protected]>
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 <[email protected]>
Signed-off-by Chris Mason <[email protected]>

---

david

author
#9 lore raw

Re: BUG at fs/btrfs/tree-log.c:3106 (Re: new integration-danger branch pushed out (kernel))

Quoted 4 lines · David Sterba

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

#10 lore raw

Re: BUG at fs/btrfs/tree-log.c:3106 (Re: new integration-danger branch pushed out (kernel))

Quoted 7 lines · Chris Mason
Quoted 4 lines · David Sterba

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

#11 lore raw

Re: BUG at fs/btrfs/tree-log.c:3106 (Re: new integration-danger branch pushed out (kernel))

In reply to David Sterba
Quoted 31 lines · David Sterba

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]
Quoted 8 lines
[ 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

#12 lore raw

Warnings and crash

In reply to Chris Mason

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

#13 lore raw

Re: Warnings and crash

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

author
#14 lore raw

Re: Warnings and crash

Quoted 6 lines · David Sterba

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

#15 lore raw

Re: Warnings and crash

On Wed, Nov 2, 2011 at 6:40 PM, Chris Mason <[email protected]> wr= ote:

Quoted 2 lines · David Sterba
Quoted 1 line

This one happened again, exactly same sequence of warnings and the c=

rash

Quoted 1 line
Quoted 1 line

at the end (same stack traces). It was in integration-scrub branch, =

ie.

Quoted 3 lines
Quoted 3 lines

with all fixes on top.

(I have captured sysrq-w, /proc/pid/stack of all processes and have =

the

Quoted 3 lines
Quoted 1 line

dmesg logs if anybody is interested.)

Yes, I'd like to see the logs. =A0We need to figure out if we just fa=

iled

Quoted 2 lines

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 [btr=
fs]
[ 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 [btr=
fs]
[ 8712.675473]  [<ffffffffa0048b49>]
btrfs_write_dirty_block_groups+0xd9/0x530 [btrfs]
[ 8712.675481]  [<ffffffffa0048952>] ? btrfs_run_delayed_refs+0xf2/0x21=
0 [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 [b=
trfs]
[ 8712.675528]  [<ffffffffa0051c80>] ? btrfs_congested_fn+0xb0/0xb0 [bt=
rfs]
[ 8712.675536]  [<ffffffffa0051c80>] ? btrfs_congested_fn+0xb0/0xb0 [bt=
rfs]
[ 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html