| Message ID | 4FF12190.9090005@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 2 July 2012 12:20, Liu Bo <liubo2009@cn.fujitsu.com> wrote: > On 07/02/2012 11:35 AM, Daniel J Blueman wrote: > >>> Hi everyone, >>> >>> I've got a nice set of fixes from Josef, Jan, Ilya and others in my >>> for-linus branch: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus >>> >>> Some of the changes are fixes for the tree logging code, so I ran some >>> extra crash runs against them Friday night. >>> >>> I ended up with a new crash in the tree log directory deletion replay >>> code, so I didn't send out the pull request to Linus. >>> >>> It isn't clear yet if the new crash is because I was testing differently >>> or if it is a regression. I'm nailing it down this weekend, but please >>> give my for-linus a shot. >> >> With this branch (3.4.0), my test has consistently been hitting the >> BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID) in >> insert_inline_extent_backref [1]. This is followed by a string of >> other issues [2] and a hard lockup, so I used netconsole to collect >> this. >> >> I'm preparing my btrfs test for xfstests integration, but can slip you >> it if interested. It hits this case in ~30s. >> > > > IMO the BUG_ON is meant to avoid to mix 'log tree' in, it should be: > > BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID && root_objectid == BTRFS_TREE_LOG_OBJECTID); > > This should help you, can you give it a try? Bo, this did address the assertion I was tripping, so looks good from here; it allowed me to report the second (different) assertion of course. If you still think the fix is sound, is it a good idea for 3.5-rc7? Thanks, Daniel
On 07/10/2012 08:18 PM, Daniel J Blueman wrote: > On 2 July 2012 12:20, Liu Bo <liubo2009@cn.fujitsu.com> wrote: >> On 07/02/2012 11:35 AM, Daniel J Blueman wrote: >> >>>> Hi everyone, >>>> >>>> I've got a nice set of fixes from Josef, Jan, Ilya and others in my >>>> for-linus branch: >>>> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus >>>> >>>> Some of the changes are fixes for the tree logging code, so I ran some >>>> extra crash runs against them Friday night. >>>> >>>> I ended up with a new crash in the tree log directory deletion replay >>>> code, so I didn't send out the pull request to Linus. >>>> >>>> It isn't clear yet if the new crash is because I was testing differently >>>> or if it is a regression. I'm nailing it down this weekend, but please >>>> give my for-linus a shot. >>> With this branch (3.4.0), my test has consistently been hitting the >>> BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID) in >>> insert_inline_extent_backref [1]. This is followed by a string of >>> other issues [2] and a hard lockup, so I used netconsole to collect >>> this. >>> >>> I'm preparing my btrfs test for xfstests integration, but can slip you >>> it if interested. It hits this case in ~30s. >>> >> >> IMO the BUG_ON is meant to avoid to mix 'log tree' in, it should be: >> >> BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID && root_objectid == BTRFS_TREE_LOG_OBJECTID); >> >> This should help you, can you give it a try? > > Bo, this did address the assertion I was tripping, so looks good from > here; it allowed me to report the second (different) assertion of > course. > > If you still think the fix is sound, is it a good idea for 3.5-rc7? > Hi Daniel, I'm sorry but it is not ready yet, as it does not catch the root cause of the bug. Josef has found that the bug comes from disabling merging delayed refs and is working on the bug with Arne. As the root cause has been found, the bug will be fixed soon IMO. Btw, while testing with your great test scripts, I also post patches for two bugs, which may have address your other issues. Their links are http://www.spinics.net/lists/linux-btrfs/msg17761.html http://www.spinics.net/lists/linux-btrfs/msg17764.html thanks, liubo > Thanks, > Daniel -- 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 July 2012 09:37, Liu Bo <liubo2009@cn.fujitsu.com> wrote: > On 07/10/2012 08:18 PM, Daniel J Blueman wrote: > >> On 2 July 2012 12:20, Liu Bo <liubo2009@cn.fujitsu.com> wrote: >>> On 07/02/2012 11:35 AM, Daniel J Blueman wrote: >>> >>>>> Hi everyone, >>>>> >>>>> I've got a nice set of fixes from Josef, Jan, Ilya and others in my >>>>> for-linus branch: >>>>> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus >>>>> >>>>> Some of the changes are fixes for the tree logging code, so I ran some >>>>> extra crash runs against them Friday night. >>>>> >>>>> I ended up with a new crash in the tree log directory deletion replay >>>>> code, so I didn't send out the pull request to Linus. >>>>> >>>>> It isn't clear yet if the new crash is because I was testing differently >>>>> or if it is a regression. I'm nailing it down this weekend, but please >>>>> give my for-linus a shot. >>>> With this branch (3.4.0), my test has consistently been hitting the >>>> BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID) in >>>> insert_inline_extent_backref [1]. This is followed by a string of >>>> other issues [2] and a hard lockup, so I used netconsole to collect >>>> this. >>>> >>>> I'm preparing my btrfs test for xfstests integration, but can slip you >>>> it if interested. It hits this case in ~30s. >>>> >>> >>> IMO the BUG_ON is meant to avoid to mix 'log tree' in, it should be: >>> >>> BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID && root_objectid == BTRFS_TREE_LOG_OBJECTID); >>> >>> This should help you, can you give it a try? >> >> Bo, this did address the assertion I was tripping, so looks good from >> here; it allowed me to report the second (different) assertion of >> course. >> >> If you still think the fix is sound, is it a good idea for 3.5-rc7? > > > Hi Daniel, > > I'm sorry but it is not ready yet, as it does not catch the root cause of the bug. > > Josef has found that the bug comes from disabling merging delayed refs and is working on the bug > with Arne. As the root cause has been found, the bug will be fixed soon IMO. Now I see the two issues are connected. > Btw, while testing with your great test scripts, I also post patches for two bugs, which may have address your > other issues. Their links are > > http://www.spinics.net/lists/linux-btrfs/msg17761.html > http://www.spinics.net/lists/linux-btrfs/msg17764.html Great work indeed! Thanks Bo, Daniel
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 4b5a1e1..a006017 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -1766,7 +1766,8 @@ int insert_inline_extent_backref(struct btrfs_trans_handle *trans, bytenr, num_bytes, parent, root_objectid, owner, offset, 1); if (ret == 0) { - BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID); + BUG_ON(owner < BTRFS_FIRST_FREE_OBJECTID && + root_objectid == BTRFS_TREE_LOG_OBJECTID); update_inline_extent_backref(trans, root, path, iref, refs_to_add, extent_op); } else if (ret == -ENOENT) {