From: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
To: David Sterba <dsterba@suse.com>, <clm@fb.com>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: [PULL] Btrfs fixes, part 3
Date: Thu, 25 Aug 2016 14:14:27 +0800 [thread overview]
Message-ID: <57BE8CC3.7070001@cn.fujitsu.com> (raw)
In-Reply-To: <cover.1472045668.git.dsterba@suse.com>
[-- Attachment #1: Type: text/plain, Size: 4151 bytes --]
Hi david and chris,
On 08/24/2016 09:42 PM, David Sterba wrote:
> Hi,
>
> this pull request contains part 2 and adds more that arrived in the meantime
> (new fixes or updated versions of patches). Assorted fixes. Please pull,
> thanks.
>
> ----------------------------------------------------------------
> The following changes since commit 10838816547a28696ca10e038b3b32f2efec5a42:
>
> Merge branch 'integration-4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux into for-linus-4.8 (2016-08-05 12:25:05 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-chris-4.8
>
> for you to fetch changes up to 79354fc603184885b50cf935b8b2085c2b3e0535:
>
> Btrfs: fix lockdep warning on deadlock against an inode's log mutex (2016-08-24 14:54:42 +0200)
>
> ----------------------------------------------------------------
> Alex Lyakas (1):
> btrfs: flush_space: treat return value of do_chunk_alloc properly
>
> Anand Jain (1):
> btrfs: do not background blkdev_put()
>
> Filipe Manana (1):
> Btrfs: fix lockdep warning on deadlock against an inode's log mutex
>
> Jeff Mahoney (3):
> btrfs: properly track when rescan worker is running
> btrfs: waiting on qgroup rescan should not always be interruptible
> btrfs: don't create or leak aliased root while cleaning up orphans
>
> Josef Bacik (2):
> Btrfs: fix em leak in find_first_block_group
> Btrfs: handle pending renames with recycled inodes properly
>
> Liu Bo (6):
> Btrfs: fix memory leak of reloc_root
> Btrfs: add ASSERT for block group's memory leak
> Btrfs: clarify do_chunk_alloc()'s return value
> Btrfs: check btree node's nritems
> Btrfs: detect corruption when non-root leaf has zero item
> Btrfs: remove BUG() in raid56
>
> Qu Wenruo (4):
> btrfs: backref: Fix soft lockup in __merge_refs function
> btrfs: qgroup: Refactor btrfs_qgroup_insert_dirty_extent()
> btrfs: relocation: Fix leaking qgroups numbers on data extents
> btrfs: qgroup: Fix qgroup incorrectness caused by log replay
>
> Wang Xiaoguang (5):
> btrfs: use correct offset for reloc_inode in prealloc_file_extent_cluster()
> btrfs: divide btrfs_update_reserved_bytes() into two functions
> btrfs: update btrfs_space_info's bytes_may_use timely
When I tested patch "btrfs: update btrfs_space_info's bytes_may_use
timely", I forgot
to run dm-flakey related fstests test cases: generic/056 generic/057
generic/059
generic/065 and generic/073, they will report a WARN about
bytes_may_use, sorry.
I prepared a patch to fix this issue, please see the attachment, with
this patch,
these 5 cases will pass.
Regards,
Xiaoguang Wang
> btrfs: should block unused block groups deletion work when allocating data space
> btrfs: fix fsfreeze hang caused by delayed iputs deal
>
> fs/btrfs/backref.c | 1 +
> fs/btrfs/ctree.h | 7 +-
> fs/btrfs/delayed-ref.c | 7 +-
> fs/btrfs/disk-io.c | 69 ++++++++++++---
> fs/btrfs/disk-io.h | 2 +
> fs/btrfs/extent-tree.c | 227 ++++++++++++++++++++++++++-----------------------
> fs/btrfs/extent_io.h | 1 +
> fs/btrfs/file.c | 28 +++---
> fs/btrfs/inode-map.c | 3 +-
> fs/btrfs/inode.c | 37 +++++---
> fs/btrfs/ioctl.c | 2 +-
> fs/btrfs/qgroup.c | 62 +++++++++++---
> fs/btrfs/qgroup.h | 36 ++++++--
> fs/btrfs/raid56.c | 5 +-
> fs/btrfs/relocation.c | 126 ++++++++++++++++++++++++---
> fs/btrfs/root-tree.c | 27 ++++--
> fs/btrfs/send.c | 36 ++++++--
> fs/btrfs/super.c | 16 ++++
> fs/btrfs/transaction.c | 7 +-
> fs/btrfs/tree-log.c | 21 ++++-
> fs/btrfs/tree-log.h | 5 +-
> fs/btrfs/volumes.c | 69 ++++++++-------
> 22 files changed, 566 insertions(+), 228 deletions(-)
> --
> 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
>
>
[-- Attachment #2: 0001-btrfs-do-not-decrease-bytes_may_use-when-replaying-e.patch --]
[-- Type: text/x-patch, Size: 1701 bytes --]
>From 37a68c327b8090ecf59e7019433638d7a569d3ab Mon Sep 17 00:00:00 2001
From: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
Date: Thu, 25 Aug 2016 10:09:09 +0800
Subject: [PATCH] btrfs: do not decrease bytes_may_use when replaying extents
When replaying extents, there is no need to update bytes_may_use
in btrfs_alloc_logged_file_extent(), otherwise it'll trigger a
WARN_ON about bytes_may_use.
Fixes: ("btrfs: update btrfs_space_info's bytes_may_use timely")
Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
---
fs/btrfs/extent-tree.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index ae8f9aa..7a15990 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -8242,6 +8242,7 @@ int btrfs_alloc_logged_file_extent(struct btrfs_trans_handle *trans,
{
int ret;
struct btrfs_block_group_cache *block_group;
+ struct btrfs_space_info *space_info;
/*
* Mixed block groups will exclude before processing the log so we only
@@ -8257,9 +8258,14 @@ int btrfs_alloc_logged_file_extent(struct btrfs_trans_handle *trans,
if (!block_group)
return -EINVAL;
- ret = btrfs_add_reserved_bytes(block_group, ins->offset,
- ins->offset, 0);
- BUG_ON(ret); /* logic error */
+ space_info = block_group->space_info;
+ spin_lock(&space_info->lock);
+ spin_lock(&block_group->lock);
+ space_info->bytes_reserved += ins->offset;
+ block_group->reserved += ins->offset;
+ spin_unlock(&block_group->lock);
+ spin_unlock(&space_info->lock);
+
ret = alloc_reserved_file_extent(trans, root, 0, root_objectid,
0, owner, offset, ins, 1);
btrfs_put_block_group(block_group);
--
2.9.0
next prev parent reply other threads:[~2016-08-25 6:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-24 13:42 [PULL] Btrfs fixes, part 3 David Sterba
2016-08-24 21:14 ` Chris Mason
2016-08-25 6:14 ` Wang Xiaoguang [this message]
2016-08-25 10:54 ` Chris Mason
2016-08-25 12:04 ` Wang Xiaoguang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57BE8CC3.7070001@cn.fujitsu.com \
--to=wangxg.fnst@cn.fujitsu.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.