All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: dsterba@suse.cz, lists@colorremedies.com
Subject: [PATCH 2/2] btrfs: extent-tree: Ensure btrfs_trim_fs can trim the whole fs
Date: Tue, 21 Nov 2017 15:21:45 +0800	[thread overview]
Message-ID: <20171121072145.24413-2-wqu@suse.com> (raw)
In-Reply-To: <20171121072145.24413-1-wqu@suse.com>

[BUG]
fstrim on some btrfs only trims the unallocated space, not trimming any
space in existing block groups.

[CAUSE]
fstrim_range passed in by default fstrim will be:

range->start = 0
range->len = fs_size (which equals with super->total_bytes)
range->min_len = 512

However btrfs_trim_fs() following above parameter to search block groups
to trim.

While it's quite possible that all chunks start beyond
super->total_bytes if the fs is balanced several times.

In that case, btrfs will skip trimming block groups and only trim the
unallocated space of each device.

[FIX]
For common full fs trimming range passed in, extent its len to (u64)-1
so we will iterate all block groups.

And for custom fs trimming range, due to the fact that the range will
always be truncated by range [0, super->total_bytes), making custom fs
trimming range useless.

Just return -ENOTTY for custom fs trimming range.

Reported-by: Chris Murphy <lists@colorremedies.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 fs/btrfs/extent-tree.c | 29 ++++++++++++++++++++++++-----
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 3a252d7af158..22bbcc8c4f6c 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -11024,12 +11024,31 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range)
 	int ret = 0;
 
 	/*
-	 * try to trim all FS space, our block group may start from non-zero.
+	 * NOTE: Btrfs uses its own logical address space, where its first
+	 * chunk can start anywhere if it wants.
+	 * If we follow common start = 0 and len = fs_size from @range, we
+	 * can end up without trimming any block groups, since it's highly
+	 * possible all chunks start beyond that range.
+	 *
+	 * So if we want to trim the whole fs, extent the len to (u64)-1 to trim
+	 * all block groups.
+	 *
+	 * Also, since @range will always be truncated to fs size, manually
+	 * passing range to trim specified range doesn't make much sense.
+	 * (No mean to trim any block group whose bytenr starts beyond
+	 *  @total_bytes)
+	 * So in that case, return -ENOTTY directly to prevent any custom trim
+	 * request.
 	 */
-	if (range->len == total_bytes)
-		cache = btrfs_lookup_first_block_group(fs_info, range->start);
-	else
-		cache = btrfs_lookup_block_group(fs_info, range->start);
+	if (range->start == 0 && range->len == total_bytes) {
+		range->len = (u64)-1;
+	} else {
+		btrfs_info(fs_info,
+		"trimming custom range is not supported due to the limitation of fstrim_range");
+		return -ENOTTY;
+	}
+
+	cache = btrfs_lookup_first_block_group(fs_info, range->start);
 
 	for (; cache; cache = next_block_group(fs_info, cache)) {
 		if (cache->key.objectid >= (range->start + range->len)) {
-- 
2.15.0


  reply	other threads:[~2017-11-21  7:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-21  7:21 [PATCH v2 1/2] btrfs: Enhance btrfs_trim_fs function to handle error better Qu Wenruo
2017-11-21  7:21 ` Qu Wenruo [this message]
2017-11-21  7:41   ` [PATCH 2/2] btrfs: extent-tree: Ensure btrfs_trim_fs can trim the whole fs Nikolay Borisov
2017-11-21  8:03     ` Qu Wenruo
2017-11-21 15:12   ` Filipe Manana
2017-11-22  0:42     ` Qu Wenruo

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=20171121072145.24413-2-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    /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.