All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: David Sterba <dsterba@suse.com>
Subject: [PATCH 1/2] btrfs-progs: device remove: add support for cancel
Date: Fri, 21 May 2021 14:06:41 +0200	[thread overview]
Message-ID: <20210521120641.16933-1-dsterba@suse.com> (raw)
In-Reply-To: <cover.1621526221.git.dsterba@suse.com>

Recognize special name 'cancel' for device deletion, that will request
kernel to stop running device deletion. This needs support in kernel,
otherwise this will fail due to another exclusive operation running
(though could be the same one).

The command returns after kernel finishes any work that got interrupted,
but this should not take long in kernels 5.10+ that allow interruptible
relocation. The waiting inside kernel is interruptible so this command
(and the waiting stage) can be interrupted.

The device size is restored when deletion does not finish but it's
recommended to review the filesystem state.

Note: in kernels 5.10+ sending a fatal signal (TERM, KILL, Ctrl-C) to
the process running the device deletion will cancel it too.

Example:

    $ btrfs device delete /dev/sdx /mnt
    ...
    $ btrfs device delete cancel /mnt

Signed-off-by: David Sterba <dsterba@suse.com>
---
 cmds/device.c | 42 +++++++++++++++++++++++++++++++++---------
 1 file changed, 33 insertions(+), 9 deletions(-)

diff --git a/cmds/device.c b/cmds/device.c
index 4d1276b949b9..48067101fa7d 100644
--- a/cmds/device.c
+++ b/cmds/device.c
@@ -194,6 +194,7 @@ static int _cmd_device_remove(const struct cmd_struct *cmd,
 	int i, fdmnt, ret = 0;
 	DIR	*dirstream = NULL;
 	bool enqueue = false;
+	bool cancel = false;
 
 	optind = 0;
 	while (1) {
@@ -225,12 +226,30 @@ static int _cmd_device_remove(const struct cmd_struct *cmd,
 	if (fdmnt < 0)
 		return 1;
 
-	ret = check_running_fs_exclop(fdmnt, BTRFS_EXCLOP_DEV_REMOVE, enqueue);
-	if (ret != 0) {
-		if (ret < 0)
-			error("unable to check status of exclusive operation: %m");
-		close_file_or_dir(fdmnt, dirstream);
-		return 1;
+	/* Scan device arguments for 'cancel', that must be the only "device" */
+	for (i = optind; i < argc - 1; i++) {
+		if (cancel) {
+			error("cancel requested but another device specified: %s\n",
+				argv[i]);
+			close_file_or_dir(fdmnt, dirstream);
+			return 1;
+		}
+		if (strcmp("cancel", argv[i]) == 0) {
+			cancel = true;
+			printf("Request to cancel running device deletion\n");
+		}
+	}
+
+	if (!cancel) {
+		ret = check_running_fs_exclop(fdmnt, BTRFS_EXCLOP_DEV_REMOVE,
+					      enqueue);
+		if (ret != 0) {
+			if (ret < 0)
+				error(
+			"unable to check status of exclusive operation: %m");
+			close_file_or_dir(fdmnt, dirstream);
+			return 1;
+		}
 	}
 
 	for(i = optind; i < argc - 1; i++) {
@@ -243,8 +262,9 @@ static int _cmd_device_remove(const struct cmd_struct *cmd,
 			argv2.devid = arg_strtou64(argv[i]);
 			argv2.flags = BTRFS_DEVICE_SPEC_BY_ID;
 			is_devid = 1;
-		} else if (path_is_block_device(argv[i]) == 1 ||
-				strcmp(argv[i], "missing") == 0) {
+		} else if (strcmp(argv[i], "missing") == 0 ||
+			   cancel ||
+			   path_is_block_device(argv[i]) == 1) {
 			strncpy_null(argv2.name, argv[i]);
 		} else {
 			error("not a block device: %s", argv[i]);
@@ -303,7 +323,11 @@ static int _cmd_device_remove(const struct cmd_struct *cmd,
 	"the device.",								\
 	"If 'missing' is specified for <device>, the first device that is",	\
 	"described by the filesystem metadata, but not present at the mount",	\
-	"time will be removed. (only in degraded mode)"
+	"time will be removed. (only in degraded mode)",			\
+	"If 'cancel' is specified as the only device to delete, request cancelation", \
+	"of a previously started device deletion and wait until kernel finishes", \
+	"any pending work. This will not delete the device and the size will be", \
+	"restored to previous state. When deletion is not running, this will fail."
 
 static const char * const cmd_device_remove_usage[] = {
 	"btrfs device remove <device>|<devid> [<device>|<devid>...] <path>",
-- 
2.29.2


  parent reply	other threads:[~2021-05-21 12:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-21 12:06 [PATCH 0/6] Support resize and device delete cancel ops David Sterba
2021-05-21 12:06 ` [PATCH 1/6] btrfs: protect exclusive_operation by super_lock David Sterba
2021-05-21 13:37   ` Josef Bacik
2021-05-21 12:06 ` [PATCH 2/6] btrfs: add cancelable chunk relocation support David Sterba
2021-05-21 13:21   ` Josef Bacik
2021-05-26 22:56     ` David Sterba
2021-06-16 13:54   ` Filipe Manana
2021-06-16 13:55     ` Filipe Manana
2021-06-16 15:53       ` David Sterba
2021-06-16 15:58       ` [PATCH v2] btrfs: add cancellable " David Sterba
2021-06-17  9:18         ` Filipe Manana
2021-05-21 12:06 ` [PATCH 3/6] btrfs: introduce try-lock semantics for exclusive op start David Sterba
2021-05-21 13:38   ` Josef Bacik
2021-05-27  7:43   ` Anand Jain
2021-05-28 12:30     ` David Sterba
2021-05-29 13:48       ` Anand Jain
2021-05-31 18:23         ` David Sterba
2021-05-21 12:06 ` [PATCH 4/6] btrfs: add wrapper for conditional start of exclusive operation David Sterba
2021-05-21 13:29   ` Josef Bacik
2021-05-21 16:45     ` David Sterba
2021-05-26 22:24       ` David Sterba
2021-05-21 12:06 ` [PATCH 5/6] btrfs: add cancelation to resize David Sterba
2021-05-21 13:38   ` Josef Bacik
2021-05-21 12:06 ` [PATCH 6/6] btrfs: add device delete cancel David Sterba
2021-05-21 13:38   ` Josef Bacik
2021-05-21 12:06 ` David Sterba [this message]
2021-05-21 12:06 ` [PATCH 2/2] btrfs-progs: fi resize: add support for cancel David Sterba
2021-12-14 14:49 ` [PATCH 0/6] Support resize and device delete cancel ops Anand Jain
2021-12-15 15:13   ` 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=20210521120641.16933-1-dsterba@suse.com \
    --to=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.