From: Nikolay Borisov <nborisov@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: Nikolay Borisov <nborisov@suse.com>
Subject: [PATCH 2/4] btrfs: Always trim all unallocated space in btrfs_trim_free_extents
Date: Mon, 3 Jun 2019 13:06:00 +0300 [thread overview]
Message-ID: <20190603100602.19362-3-nborisov@suse.com> (raw)
In-Reply-To: <20190603100602.19362-1-nborisov@suse.com>
This patch removes support for range parameters of FITRIM ioctl when
trimming unallocated space on devices. This is necessary since ranges
passed from user space are generally interpreted as logical addresses,
whereas btrfs_trim_free_extents used to interpret them as device
physical extents. This could result in counter-intuitive behavior for
users so it's best to remove that support altogether.
Additionally, the existing range support had a bug where if an offset
was passed to FITRIM which overflows u64 e.g. -1 (parsed as u64
18446744073709551615) then wrong data was fed into btrfs_issue_discard,
which in turn leads to wrap-around when aligning the passed range and
results in wrong regions being discarded which leads to data corruption.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
---
fs/btrfs/extent-tree.c | 28 +++-------------------------
1 file changed, 3 insertions(+), 25 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 96628eb4b389..d8c5febf7636 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -11145,13 +11145,11 @@ int btrfs_error_unpin_extent_range(struct btrfs_fs_info *fs_info,
* it while performing the free space search since we have already
* held back allocations.
*/
-static int btrfs_trim_free_extents(struct btrfs_device *device,
- struct fstrim_range *range, u64 *trimmed)
+static int btrfs_trim_free_extents(struct btrfs_device *device, u64 *trimmed)
{
- u64 start, len = 0, end = 0;
+ u64 start = SZ_1M, len = 0, end = 0;
int ret;
- start = max_t(u64, range->start, SZ_1M);
*trimmed = 0;
/* Discard not supported = nothing to do. */
@@ -11194,22 +11192,6 @@ static int btrfs_trim_free_extents(struct btrfs_device *device,
break;
}
- /* Keep going until we satisfy minlen or reach end of space */
- if (len < range->minlen) {
- mutex_unlock(&fs_info->chunk_mutex);
- start += len;
- continue;
- }
-
- /* If we are out of the passed range break */
- if (start > range->start + range->len - 1) {
- mutex_unlock(&fs_info->chunk_mutex);
- break;
- }
-
- start = max(range->start, start);
- len = min(range->len, len);
-
ret = btrfs_issue_discard(device->bdev, start, len,
&bytes);
if (!ret)
@@ -11224,10 +11206,6 @@ static int btrfs_trim_free_extents(struct btrfs_device *device,
start += len;
*trimmed += bytes;
- /* We've trimmed enough */
- if (*trimmed >= range->len)
- break;
-
if (fatal_signal_pending(current)) {
ret = -ERESTARTSYS;
break;
@@ -11311,7 +11289,7 @@ int btrfs_trim_fs(struct btrfs_fs_info *fs_info, struct fstrim_range *range)
mutex_lock(&fs_info->fs_devices->device_list_mutex);
devices = &fs_info->fs_devices->devices;
list_for_each_entry(device, devices, dev_list) {
- ret = btrfs_trim_free_extents(device, range, &group_trimmed);
+ ret = btrfs_trim_free_extents(device, &group_trimmed);
if (ret) {
dev_failed++;
dev_ret = ret;
--
2.17.1
next prev parent reply other threads:[~2019-06-03 10:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-03 10:05 [PATCH 0/4] Further FITRIM improvements Nikolay Borisov
2019-06-03 10:05 ` [PATCH 1/4] btrfs: Document __etree_search Nikolay Borisov
2019-06-05 8:04 ` Johannes Thumshirn
2019-06-05 9:13 ` Qu Wenruo
2019-06-05 11:50 ` [PATCH v2] " Nikolay Borisov
2019-06-05 11:51 ` Johannes Thumshirn
2019-06-03 10:06 ` Nikolay Borisov [this message]
2019-06-05 9:13 ` [PATCH 2/4] btrfs: Always trim all unallocated space in btrfs_trim_free_extents Qu Wenruo
2019-06-03 10:06 ` [PATCH 3/4] btrfs: Skip first megabyte on device when trimming Nikolay Borisov
2019-06-05 8:06 ` Johannes Thumshirn
2019-06-05 9:14 ` Qu Wenruo
2019-06-05 11:18 ` Nikolay Borisov
2019-06-03 10:06 ` [PATCH 4/4] btrfs: Don't trim returned range based on input value in find_first_clear_extent_bit Nikolay Borisov
2019-06-05 9:25 ` Qu Wenruo
2019-06-07 13:28 ` [PATCH 0/4] Further FITRIM improvements David Sterba
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=20190603100602.19362-3-nborisov@suse.com \
--to=nborisov@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox