* [PATCH v3 0/2] btrfs: Set relative data on clear btrfs_block_group_cache->pinned
@ 2015-02-26 6:48 Zhaolei
2015-02-26 6:48 ` [PATCH v3 1/2] " Zhaolei
2015-02-26 6:48 ` [PATCH v3 2/2] btrfs: add WARN_ON() to check is space_info op current Zhaolei
0 siblings, 2 replies; 3+ messages in thread
From: Zhaolei @ 2015-02-26 6:48 UTC (permalink / raw)
To: linux-btrfs; +Cc: Zhao Lei
From: Zhao Lei <zhaolei@cn.fujitsu.com>
Changelog v1->v2:
[PATCH 2/2] btrfs: add WARN_ON() to check is space_info op current
Put WARN_ON()s under the ENOSPC_DEBUG mount option.
Suggested by: David Sterba <dsterba@suse.cz>
Changelog v1->v2:
drop patch of:
Remove BUG_ON() when failed searching block_group_cache in unpin_extent_range()
because Filipe Manana <fdmanana@suse.com> already fixed it with better way.
Zhao Lei (2):
btrfs: Set relative data on clear btrfs_block_group_cache->pinned
btrfs: add WARN_ON() to check is space_info op current
fs/btrfs/extent-tree.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
--
1.8.5.1
^ permalink raw reply [flat|nested] 3+ messages in thread
* [PATCH v3 1/2] btrfs: Set relative data on clear btrfs_block_group_cache->pinned
2015-02-26 6:48 [PATCH v3 0/2] btrfs: Set relative data on clear btrfs_block_group_cache->pinned Zhaolei
@ 2015-02-26 6:48 ` Zhaolei
2015-02-26 6:48 ` [PATCH v3 2/2] btrfs: add WARN_ON() to check is space_info op current Zhaolei
1 sibling, 0 replies; 3+ messages in thread
From: Zhaolei @ 2015-02-26 6:48 UTC (permalink / raw)
To: linux-btrfs; +Cc: Zhao Lei
From: Zhao Lei <zhaolei@cn.fujitsu.com>
Bug1:
space_info->bytes_readonly was set to very large(negative) value in
btrfs_remove_block_group().
Reason:
Current code set block_group_cache->pinned = 0 in btrfs_delete_unused_bgs(),
but above space was not counted to space_info->bytes_readonly.
Then in btrfs_remove_block_group():
block_group->space_info->bytes_readonly -= block_group->key.offset;
We can see following value in trace:
btrfs_remove_block_group: pid=2677 comm=btrfs-cleaner WARNING: bytes_readonly=12582912, key.offset=134217728
Bug2:
space_info->total_bytes_pinned grow to value larger than fs size.
In a 1.2G fs, we can get following trace log:
at first:
ZL_DEBUG: add_pinned_bytes: pid=2710 comm=sync change total_bytes_pinned flags=1 869793792 + 95944704 = 965738496
after some op:
ZL_DEBUG: add_pinned_bytes: pid=2770 comm=sync change total_bytes_pinned flags=1 1780178944 + 95944704 = 1876123648
after some op:
ZL_DEBUG: add_pinned_bytes: pid=3193 comm=sync change total_bytes_pinned flags=1 2924568576 + 95551488 = 3020120064
...
Reason:
Similar to bug1, we also need to adjust space_info->total_bytes_pinned
in above code block.
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
---
fs/btrfs/extent-tree.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index dc25e13..bfb9105 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -9605,8 +9605,18 @@ void btrfs_delete_unused_bgs(struct btrfs_fs_info *fs_info)
mutex_unlock(&fs_info->unused_bg_unpin_mutex);
/* Reset pinned so btrfs_put_block_group doesn't complain */
+ spin_lock(&space_info->lock);
+ spin_lock(&block_group->lock);
+
+ space_info->bytes_pinned -= block_group->pinned;
+ space_info->bytes_readonly += block_group->pinned;
+ percpu_counter_add(&space_info->total_bytes_pinned,
+ -block_group->pinned);
block_group->pinned = 0;
+ spin_unlock(&block_group->lock);
+ spin_unlock(&space_info->lock);
+
/*
* Btrfs_remove_chunk will abort the transaction if things go
* horribly wrong.
--
1.8.5.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* [PATCH v3 2/2] btrfs: add WARN_ON() to check is space_info op current
2015-02-26 6:48 [PATCH v3 0/2] btrfs: Set relative data on clear btrfs_block_group_cache->pinned Zhaolei
2015-02-26 6:48 ` [PATCH v3 1/2] " Zhaolei
@ 2015-02-26 6:48 ` Zhaolei
1 sibling, 0 replies; 3+ messages in thread
From: Zhaolei @ 2015-02-26 6:48 UTC (permalink / raw)
To: linux-btrfs; +Cc: Zhao Lei
From: Zhao Lei <zhaolei@cn.fujitsu.com>
space_info's value calculation is some complex and easy to cause
bug, add WARN_ON() to help debug.
Changelog v1->v2:
Put WARN_ON()s under the ENOSPC_DEBUG mount option.
Suggested by: David Sterba <dsterba@suse.cz>
Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
---
fs/btrfs/extent-tree.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index bfb9105..6c19033 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -9415,9 +9415,19 @@ int btrfs_remove_block_group(struct btrfs_trans_handle *trans,
spin_lock(&block_group->space_info->lock);
list_del_init(&block_group->ro_list);
+
+ if (btrfs_test_opt(root, ENOSPC_DEBUG)) {
+ WARN_ON(block_group->space_info->total_bytes
+ < block_group->key.offset);
+ WARN_ON(block_group->space_info->bytes_readonly
+ < block_group->key.offset);
+ WARN_ON(block_group->space_info->disk_total
+ < block_group->key.offset * factor);
+ }
block_group->space_info->total_bytes -= block_group->key.offset;
block_group->space_info->bytes_readonly -= block_group->key.offset;
block_group->space_info->disk_total -= block_group->key.offset * factor;
+
spin_unlock(&block_group->space_info->lock);
memcpy(&key, &block_group->key, sizeof(key));
--
1.8.5.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-02-26 6:49 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-26 6:48 [PATCH v3 0/2] btrfs: Set relative data on clear btrfs_block_group_cache->pinned Zhaolei
2015-02-26 6:48 ` [PATCH v3 1/2] " Zhaolei
2015-02-26 6:48 ` [PATCH v3 2/2] btrfs: add WARN_ON() to check is space_info op current Zhaolei
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).