[PATCH v5 0/3] Add cli and ioctl to deregister devices

[PATCH v5 0/3] Add cli and ioctl to deregister devices

[Anand Jain]

Add ability to deregister a or all devices. I have named this sub cmd
as deregister, but I am open to your suggestions.

Further I am using /dev/btrfs-control and struct btrfs_ioctl_vol_args
for now, just similar to other ioctls in super.c including btrfs dev
scan, if rather it makes sense to use btrfs_ioctl_vol_args_v2 I shall.
Oepn to suggestions.

Kernel:
Patch 1/3 is preparatory patch, provides helper to delete a device.
Patch 2/3 adds ioctl to delete device from the device list.
Patch 3/3 provides default feature to delete all fs_devices in the list.

btrfs-progs:
Patch 1/2 introduce 'btrfs dev deregister <device>'
Patch 2/2 make the device optional and when not provided, deregisters all
unmounted devices.

v2:
  Accepted review from Nikolay, details are in the specific patch.
  Patch 1/2 is renamed from
    [PATCH 1/2] btrfs: refactor btrfs_free_stale_device() to get device list delete
  to
    [PATCH 1/2] btrfs: add function to device list delete
v3:
  No change. Send to correct ML.
v4:
  No change. But as the ML thread may be confusing, so resend.
v5:
  Mainly adds feature to deregister all unmounted devices.
  Accepts review from David, for details ref change log.

Anand Jain (3):
  btrfs: add function to device list delete
  btrfs: introduce feature to deregister a btrfs device
  btrfs: add feature to deregister all unmounted devices

 fs/btrfs/super.c           |   9 ++++
 fs/btrfs/volumes.c         | 119 +++++++++++++++++++++++++++++++++++++++++++++
 fs/btrfs/volumes.h         |   3 ++
 include/uapi/linux/btrfs.h |   9 +++-
 4 files changed, 138 insertions(+), 2 deletions(-)

Anand Jain (2):
  btrfs-progs: add 'btrfs device unregister' cli
  btrfs-progs: add feature to deregister all devices

 cmds-device.c | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 ioctl.h       |  8 +++++-
 2 files changed, 89 insertions(+), 1 deletion(-)

-- 
2.7.0

[PATCH v5 1/3] btrfs: add function to device list delete

[Anand Jain]

We need device delete from the dev_list so create a new function.
New instead of refactor of btrfs_free_stale_device() because,
btrfs_free_stale_device() doesn't hold device_list_mutex which
is actually needed here.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
v1: title of this patch
  btrfs: refactor btrfs_free_stale_device() to get device list delete
v2:
 delete_device_from_list() is not pealed from btrfs_free_stale_device()
 as this needs device_list_mutex. And its static now.
v3: Send to correct ML
v4: no change
v5: use helper free_device()

 fs/btrfs/volumes.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index d0dd0eb3d2e5..f53d62e92fa9 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -607,6 +607,26 @@ static void pending_bios_fn(struct btrfs_work *work)
 	run_scheduled_bios(device);
 }
 
+static void delete_device_from_list(struct btrfs_device *device)
+{
+	struct btrfs_fs_devices *fs_devices;
+
+	fs_devices = device->fs_devices;
+
+	lockdep_assert_held(&uuid_mutex);
+
+	mutex_lock(&fs_devices->device_list_mutex);
+	fs_devices->num_devices--;
+	list_del(&device->dev_list);
+	mutex_unlock(&fs_devices->device_list_mutex);
+
+	free_device(device);
+	if (fs_devices->num_devices == 0) {
+		btrfs_sysfs_remove_fsid(fs_devices);
+		list_del(&fs_devices->list);
+		free_fs_devices(fs_devices);
+	}
+}
 
 static void btrfs_free_stale_device(struct btrfs_device *cur_dev)
 {
-- 
2.7.0

[PATCH v5 2/3] btrfs: introduce feature to deregister a btrfs device

[Anand Jain]

Support for a new command is being added here:
 btrfs dev deregister <dev>
Which shall undo the effects of the command
 btrfs dev scan <dev>

This cli/ioctl is needed as there is no way to continue to mount in
degraded mode if the device is already scanned, which is required to
recover from the split brain raid conditions.

This patch proposes to use ioctl #5 as it was empty.
	IOW(BTRFS_IOCTL_MAGIC, 5, ..)

Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
v2: Use -EBUSY instead of -ENOENT
    Since now delete_device_from_list() holds device_list_mutex
    so dont hold device_list_mutex in its parent. Reword and indent
    pr_err/info.
v3: Send to correct ML
v4: no change.
v5: Make sure uuid_mutex in device_list_remove(), set ret value to near
to the event.

 fs/btrfs/super.c           |  4 +++
 fs/btrfs/volumes.c         | 76 ++++++++++++++++++++++++++++++++++++++++++++++
 fs/btrfs/volumes.h         |  2 ++
 include/uapi/linux/btrfs.h |  3 +-
 4 files changed, 84 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index f443517fa2f8..ea6fe4742834 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -2212,6 +2212,10 @@ static long btrfs_control_ioctl(struct file *file, unsigned int cmd,
 		ret = btrfs_scan_one_device(vol->name, FMODE_READ,
 					    &btrfs_fs_type, &fs_devices);
 		break;
+	case BTRFS_IOC_PURGE_DEV:
+		ret = btrfs_purge_one_device(vol->name, FMODE_READ,
+					    &btrfs_fs_type, &fs_devices);
+		break;
 	case BTRFS_IOC_DEVICES_READY:
 		ret = btrfs_scan_one_device(vol->name, FMODE_READ,
 					    &btrfs_fs_type, &fs_devices);
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index f53d62e92fa9..5adab70c7658 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1260,6 +1260,82 @@ static int btrfs_read_disk_super(struct block_device *bdev, u64 bytenr,
 	return 0;
 }
 
+static int device_list_remove(struct btrfs_super_block *disk_super, u64 devid)
+{
+	struct btrfs_fs_devices *fs_devices;
+	struct btrfs_device *device;
+	int ret;
+
+	mutex_lock(&uuid_mutex);
+	fs_devices = find_fsid(disk_super->fsid);
+	if (!fs_devices) {
+		ret = -ENOENT;
+		goto out;
+	}
+
+	if (fs_devices->opened) {
+		ret = -EBUSY;
+		goto out;
+	}
+
+	device = find_device(fs_devices, devid, disk_super->dev_item.uuid);
+	if (!device) {
+		ret = -ENOENT;
+		goto out;
+	}
+
+	delete_device_from_list(device);
+	ret = 0;
+out:
+	mutex_unlock(&uuid_mutex);
+
+	return ret;
+}
+
+int btrfs_purge_one_device(const char *path, fmode_t flags, void *holder,
+			  struct btrfs_fs_devices **fs_devices_ret)
+{
+	struct btrfs_super_block *disk_super;
+	struct block_device *bdev;
+	struct page *page;
+	u64 bytenr;
+	u64 devid;
+	int ret;
+
+	bytenr = btrfs_sb_offset(0);
+	flags |= FMODE_EXCL;
+
+	bdev = blkdev_get_by_path(path, flags, holder);
+	if (IS_ERR(bdev))
+		return PTR_ERR(bdev);
+
+	if (btrfs_read_disk_super(bdev, bytenr, &page, &disk_super)) {
+		ret = -EINVAL;
+		goto error_bdev_put;
+	}
+
+	devid = btrfs_stack_device_id(&disk_super->dev_item);
+
+	ret = device_list_remove(disk_super, devid);
+	/* User error */
+	if (ret == -ENOENT)
+		goto error;
+
+	if (ret)
+		pr_err("BTRFS: %pU device %s devid %llu failed to deregister: %d\n",
+			disk_super->fsid, path, devid, ret);
+	else
+		pr_info("BTRFS: %pU device %s devid %llu deregistered\n",
+			disk_super->fsid, path, devid);
+
+error:
+	btrfs_release_disk_super(page);
+
+error_bdev_put:
+	blkdev_put(bdev, flags);
+	return ret;
+}
+
 /*
  * Look for a btrfs signature on a device. This may be called out of the mount path
  * and we are not allowed to call set_blocksize during the scan. The superblock
diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
index efb5117301b7..8389d2815750 100644
--- a/fs/btrfs/volumes.h
+++ b/fs/btrfs/volumes.h
@@ -422,6 +422,8 @@ int btrfs_open_devices(struct btrfs_fs_devices *fs_devices,
 		       fmode_t flags, void *holder);
 int btrfs_scan_one_device(const char *path, fmode_t flags, void *holder,
 			  struct btrfs_fs_devices **fs_devices_ret);
+int btrfs_purge_one_device(const char *path, fmode_t flags, void *holder,
+			  struct btrfs_fs_devices **fs_devices_ret);
 int btrfs_close_devices(struct btrfs_fs_devices *fs_devices);
 void btrfs_close_extra_devices(struct btrfs_fs_devices *fs_devices, int step);
 void btrfs_assign_next_active_device(struct btrfs_fs_info *fs_info,
diff --git a/include/uapi/linux/btrfs.h b/include/uapi/linux/btrfs.h
index adf0b088d9a0..de0f1144d945 100644
--- a/include/uapi/linux/btrfs.h
+++ b/include/uapi/linux/btrfs.h
@@ -105,7 +105,6 @@ struct btrfs_ioctl_qgroup_limit_args {
  * - BTRFS_IOC_SUBVOL_GETFLAGS
  * - BTRFS_IOC_SUBVOL_SETFLAGS
  */
-
 struct btrfs_ioctl_vol_args_v2 {
 	__s64 fd;
 	__u64 transid;
@@ -744,6 +743,8 @@ enum btrfs_err_code {
 				   struct btrfs_ioctl_vol_args)
 #define BTRFS_IOC_SCAN_DEV _IOW(BTRFS_IOCTL_MAGIC, 4, \
 				   struct btrfs_ioctl_vol_args)
+#define BTRFS_IOC_PURGE_DEV _IOW(BTRFS_IOCTL_MAGIC, 5, \
+				   struct btrfs_ioctl_vol_args)
 /* trans start and trans end are dangerous, and only for
  * use by applications that know how to avoid the
  * resulting deadlocks
-- 
2.7.0

[PATCH v5 3/3] btrfs: add feature to deregister all unmounted devices

[Anand Jain]

This adds a feature to remove all registered/scanned devices,
which are not mounted or it got staled by some means.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Suggested-by: David Sterba <dsterba@suse.cz>
---
v2-4: Does not exist.

 fs/btrfs/super.c           |  7 ++++++-
 fs/btrfs/volumes.c         | 23 +++++++++++++++++++++++
 fs/btrfs/volumes.h         |  1 +
 include/uapi/linux/btrfs.h |  6 +++++-
 4 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index ea6fe4742834..409804843b74 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -2213,7 +2213,12 @@ static long btrfs_control_ioctl(struct file *file, unsigned int cmd,
 					    &btrfs_fs_type, &fs_devices);
 		break;
 	case BTRFS_IOC_PURGE_DEV:
-		ret = btrfs_purge_one_device(vol->name, FMODE_READ,
+		if (vol->ioctl_flag & ~BTRFS_IOCTL_PURGE_ALL_DEVS)
+			return -EOPNOTSUPP;
+		if (vol->ioctl_flag & BTRFS_IOCTL_PURGE_ALL_DEVS)
+			ret = btrfs_purge_devices();
+		else
+			ret = btrfs_purge_one_device(vol->name, FMODE_READ,
 					    &btrfs_fs_type, &fs_devices);
 		break;
 	case BTRFS_IOC_DEVICES_READY:
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 5adab70c7658..9fa2539a8493 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1336,6 +1336,29 @@ int btrfs_purge_one_device(const char *path, fmode_t flags, void *holder,
 	return ret;
 }
 
+int btrfs_purge_devices(void)
+{
+	struct btrfs_fs_devices *fs_devices, *tmp;
+
+	mutex_lock(&uuid_mutex);
+	list_for_each_entry_safe(fs_devices, tmp, &fs_uuids, list) {
+		/*
+		 * For now ignore stale device within a mounted FS.
+		 */
+		if (fs_devices->opened)
+			continue;
+
+		pr_info("BTRFS: %pU num_devices %llu deregistered",
+			fs_devices->fsid, fs_devices->num_devices);
+		btrfs_sysfs_remove_fsid(fs_devices);
+		list_del(&fs_devices->list);
+		free_fs_devices(fs_devices);
+	}
+	mutex_unlock(&uuid_mutex);
+
+	return 0;
+}
+
 /*
  * Look for a btrfs signature on a device. This may be called out of the mount path
  * and we are not allowed to call set_blocksize during the scan. The superblock
diff --git a/fs/btrfs/volumes.h b/fs/btrfs/volumes.h
index 8389d2815750..dec27ee4f67d 100644
--- a/fs/btrfs/volumes.h
+++ b/fs/btrfs/volumes.h
@@ -424,6 +424,7 @@ int btrfs_scan_one_device(const char *path, fmode_t flags, void *holder,
 			  struct btrfs_fs_devices **fs_devices_ret);
 int btrfs_purge_one_device(const char *path, fmode_t flags, void *holder,
 			  struct btrfs_fs_devices **fs_devices_ret);
+int btrfs_purge_devices(void);
 int btrfs_close_devices(struct btrfs_fs_devices *fs_devices);
 void btrfs_close_extra_devices(struct btrfs_fs_devices *fs_devices, int step);
 void btrfs_assign_next_active_device(struct btrfs_fs_info *fs_info,
diff --git a/include/uapi/linux/btrfs.h b/include/uapi/linux/btrfs.h
index de0f1144d945..eaf6ef04b300 100644
--- a/include/uapi/linux/btrfs.h
+++ b/include/uapi/linux/btrfs.h
@@ -28,8 +28,12 @@
 
 /* this should be 4k */
 #define BTRFS_PATH_NAME_MAX 4087
+#define BTRFS_IOCTL_PURGE_ALL_DEVS	(1ULL << 0)
 struct btrfs_ioctl_vol_args {
-	__s64 fd;
+	union {
+		__s64 fd;
+		__u64 ioctl_flag;
+	};
 	char name[BTRFS_PATH_NAME_MAX + 1];
 };
 
-- 
2.7.0

Re: [PATCH v5 0/3] Add cli and ioctl to deregister devices

[Austin S. Hemmelgarn]

On 2017-12-07 09:36, Anand Jain wrote:
> Add ability to deregister a or all devices. I have named this sub cmd
> as deregister, but I am open to your suggestions.
Being a bit picky here, but from the perspective of a native speaker of 
American English, I would say that 'deregister' sounds rather synthetic 
and somewhat harsh and alien.

Given that, as odd as it sounds, I think 'ignore' might be a more user 
friendly name for the sub-command.  It accurately describes what the 
command is doing (telling the kernel to ignore the device), and it's a 
lot less alien sounding than 'deregister'.

If you're set on having it be based on the word 'register', I would 
suggest changing it to 'unregister', as I think that sounds more natural 
than 'deregister'.

Additionally, if you do continue with 'deregister' or go with 
'unregister' as the name though, I would suggest adding 'register' as a 
synonym for the 'scan' sub-command to keep things reasonably symmetrical.
> 
> Further I am using /dev/btrfs-control and struct btrfs_ioctl_vol_args
> for now, just similar to other ioctls in super.c including btrfs dev
> scan, if rather it makes sense to use btrfs_ioctl_vol_args_v2 I shall.
> Oepn to suggestions.
> 
> Kernel:
> Patch 1/3 is preparatory patch, provides helper to delete a device.
> Patch 2/3 adds ioctl to delete device from the device list.
> Patch 3/3 provides default feature to delete all fs_devices in the list.
> 
> btrfs-progs:
> Patch 1/2 introduce 'btrfs dev deregister <device>'
> Patch 2/2 make the device optional and when not provided, deregisters all
> unmounted devices.
> 
> v2:
>    Accepted review from Nikolay, details are in the specific patch.
>    Patch 1/2 is renamed from
>      [PATCH 1/2] btrfs: refactor btrfs_free_stale_device() to get device list delete
>    to
>      [PATCH 1/2] btrfs: add function to device list delete
> v3:
>    No change. Send to correct ML.
> v4:
>    No change. But as the ML thread may be confusing, so resend.
> v5:
>    Mainly adds feature to deregister all unmounted devices.
>    Accepts review from David, for details ref change log.
> 
> Anand Jain (3):
>    btrfs: add function to device list delete
>    btrfs: introduce feature to deregister a btrfs device
>    btrfs: add feature to deregister all unmounted devices
> 
>   fs/btrfs/super.c           |   9 ++++
>   fs/btrfs/volumes.c         | 119 +++++++++++++++++++++++++++++++++++++++++++++
>   fs/btrfs/volumes.h         |   3 ++
>   include/uapi/linux/btrfs.h |   9 +++-
>   4 files changed, 138 insertions(+), 2 deletions(-)
> 
> Anand Jain (2):
>    btrfs-progs: add 'btrfs device unregister' cli
>    btrfs-progs: add feature to deregister all devices
> 
>   cmds-device.c | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   ioctl.h       |  8 +++++-
>   2 files changed, 89 insertions(+), 1 deletion(-)
> 

[PATCH v5 1/2] btrfs-progs: add cli to deregister a device

[Anand Jain]

This patch adds
  btrfs device deregister <dev>
so that an already registered device (through scan) can be deregistered.

This change is compatible with older kernel without the ioctl
BTRFS_IOC_PURGE_DEV it shall report 'Inappropriate ioctl for device'.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
v1-4: No change.
v5: make provision to add no option to delete all fsids

 cmds-device.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 ioctl.h       |  2 ++
 2 files changed, 57 insertions(+)

diff --git a/cmds-device.c b/cmds-device.c
index f4cdb39f64ac..8244ff9802be 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -329,6 +329,60 @@ out:
 	return !!ret;
 }
 
+static const char * const cmd_device_deregister_usage[] = {
+	"btrfs device deregister [<device>]",
+	"Deregister device in btrfs kernel module.",
+	NULL
+};
+
+static int btrfs_deregister_one_device(char *path)
+{
+	struct btrfs_ioctl_vol_args args;
+	int fd;
+	int ret;
+
+	fd = open("/dev/btrfs-control", O_RDWR);
+	if (fd < 0)
+		return -errno;
+
+	memset(&args, 0, sizeof(args));
+	strncpy_null(args.name, path);
+	ret = ioctl(fd, BTRFS_IOC_DEREGISTER_DEV, &args);
+	if (ret)
+		ret = -errno;
+	close(fd);
+	return ret;
+}
+
+static int cmd_device_deregister(int argc, char **argv)
+{
+	char *path;
+	int ret = 0;
+
+	if (check_argc_exact(argc - optind, 1))
+		usage(cmd_device_deregister_usage);
+
+	if (is_block_device(argv[1]) != 1) {
+		error("Not a block device: %s", argv[1]);
+		return -ENOENT;
+	}
+
+	path = canonicalize_path(argv[1]);
+	if (!path) {
+		error("Could not canonicalize path '%s': %s",
+					argv[1], strerror(errno));
+		return -ENOENT;
+	}
+
+	ret  = btrfs_deregister_one_device(path);
+	if (ret)
+		error("Can't deregister '%s': %s", path, strerror(-ret));
+
+	free(path);
+
+	return ret;
+}
+
 static const char * const cmd_device_ready_usage[] = {
 	"btrfs device ready <device>",
 	"Check device to see if it has all of its devices in cache for mounting",
@@ -604,6 +658,7 @@ const struct cmd_group device_cmd_group = {
 			CMD_ALIAS },
 		{ "remove", cmd_device_remove, cmd_device_remove_usage, NULL, 0 },
 		{ "scan", cmd_device_scan, cmd_device_scan_usage, NULL, 0 },
+		{ "deregister", cmd_device_deregister, cmd_device_deregister_usage, NULL, 0 },
 		{ "ready", cmd_device_ready, cmd_device_ready_usage, NULL, 0 },
 		{ "stats", cmd_device_stats, cmd_device_stats_usage, NULL, 0 },
 		{ "usage", cmd_device_usage,
diff --git a/ioctl.h b/ioctl.h
index 709e996f401c..3cdb88eb5bb2 100644
--- a/ioctl.h
+++ b/ioctl.h
@@ -721,6 +721,8 @@ static inline char *btrfs_err_str(enum btrfs_err_code err_code)
 				   struct btrfs_ioctl_vol_args)
 #define BTRFS_IOC_SCAN_DEV _IOW(BTRFS_IOCTL_MAGIC, 4, \
 				   struct btrfs_ioctl_vol_args)
+#define BTRFS_IOC_DEREGISTER_DEV _IOW(BTRFS_IOCTL_MAGIC, 5, \
+				   struct btrfs_ioctl_vol_args)
 /* trans start and trans end are dangerous, and only for
  * use by applications that know how to avoid the
  * resulting deadlocks
-- 
2.7.0

[PATCH v5 2/2] btrfs-progs: add feature to deregister all devices

[Anand Jain]

This patch adds default no option to deregister all unmounted
devices in the kernel at once. For example:
  btrfs device deregister

Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
v1-4: NA.
v5: New patch in v5.

 cmds-device.c | 31 +++++++++++++++++++++++++++++--
 ioctl.h       |  6 +++++-
 2 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/cmds-device.c b/cmds-device.c
index 8244ff9802be..6b9c3616b641 100644
--- a/cmds-device.c
+++ b/cmds-device.c
@@ -331,10 +331,30 @@ out:
 
 static const char * const cmd_device_deregister_usage[] = {
 	"btrfs device deregister [<device>]",
-	"Deregister device in btrfs kernel module.",
+	"Deregister one or all scanned device(s) in the kernel.",
 	NULL
 };
 
+static int btrfs_deregister_devices(void)
+{
+	struct btrfs_ioctl_vol_args args;
+	int fd;
+	int ret;
+
+	fd = open("/dev/btrfs-control", O_RDWR);
+	if (fd < 0)
+		return -errno;
+
+	memset(&args, 0, sizeof(args));
+	args.ioctl_flag = BTRFS_IOCTL_PURGE_ALL_DEVS;
+	ret = ioctl(fd, BTRFS_IOC_DEREGISTER_DEV, &args);
+	if (ret)
+		ret = -errno;
+	close(fd);
+	return ret;
+
+}
+
 static int btrfs_deregister_one_device(char *path)
 {
 	struct btrfs_ioctl_vol_args args;
@@ -359,9 +379,16 @@ static int cmd_device_deregister(int argc, char **argv)
 	char *path;
 	int ret = 0;
 
-	if (check_argc_exact(argc - optind, 1))
+	if (check_argc_max(argc - optind, 1))
 		usage(cmd_device_deregister_usage);
 
+	if (argc == 1) {
+		ret = btrfs_deregister_devices();
+		if (ret)
+			error("Can't deregister: %s", strerror(-ret));
+		return ret;
+	}
+
 	if (is_block_device(argv[1]) != 1) {
 		error("Not a block device: %s", argv[1]);
 		return -ENOENT;
diff --git a/ioctl.h b/ioctl.h
index 3cdb88eb5bb2..a36055b453e2 100644
--- a/ioctl.h
+++ b/ioctl.h
@@ -41,8 +41,12 @@ extern "C" {
 
 /* this should be 4k */
 #define BTRFS_PATH_NAME_MAX 4087
+#define BTRFS_IOCTL_PURGE_ALL_DEVS	(1ULL << 0)
 struct btrfs_ioctl_vol_args {
-	__s64 fd;
+	union {
+		__s64 fd;
+		__u64 ioctl_flag;
+	};
 	char name[BTRFS_PATH_NAME_MAX + 1];
 };
 BUILD_ASSERT(sizeof(struct btrfs_ioctl_vol_args) == 4096);
-- 
2.7.0

Re: [PATCH v5 0/3] Add cli and ioctl to deregister devices

[Anand Jain]

On 12/07/2017 10:52 PM, Austin S. Hemmelgarn wrote:
> On 2017-12-07 09:36, Anand Jain wrote:
>> Add ability to deregister a or all devices. I have named this sub cmd
>> as deregister, but I am open to your suggestions.
> Being a bit picky here, but from the perspective of a native speaker of 
> American English, I would say that 'deregister' sounds rather synthetic 
> and somewhat harsh and alien.
> 
> Given that, as odd as it sounds, I think 'ignore' might be a more user 
> friendly name for the sub-command.  It accurately describes what the 
> command is doing (telling the kernel to ignore the device), and it's a 
> lot less alien sounding than 'deregister'.
> 
> If you're set on having it be based on the word 'register', I would 
> suggest changing it to 'unregister', as I think that sounds more natural 
> than 'deregister'.
> 
> Additionally, if you do continue with 'deregister' or go with 
> 'unregister' as the name though, I would suggest adding 'register' as a 
> synonym for the 'scan' sub-command to keep things reasonably symmetrical.

  A look up on unregister lead me to use deregister as more appropriate.
  Anyway I won't bother much, I will be go be suggestions, and how
  about unscan, since scan is already there. OR how about purge.

Thanks, Anand.

Re: [PATCH v5 0/3] Add cli and ioctl to deregister devices

[Duncan]

Anand Jain posted on Fri, 08 Dec 2017 08:51:43 +0800 as excerpted:

> On 12/07/2017 10:52 PM, Austin S. Hemmelgarn wrote:
>> On 2017-12-07 09:36, Anand Jain wrote:
>>> Add ability to deregister a or all devices. I have named this sub cmd
>>> as deregister, but I am open to your suggestions.
>> Being a bit picky here, but from the perspective of a native speaker of
>> American English, I would say that 'deregister' sounds rather synthetic
>> and somewhat harsh and alien.
>> 
>> Given that, as odd as it sounds, I think 'ignore' might be a more user
>> friendly name for the sub-command.  It accurately describes what the
>> command is doing (telling the kernel to ignore the device), and it's a
>> lot less alien sounding than 'deregister'.
>> 
>> If you're set on having it be based on the word 'register', I would
>> suggest changing it to 'unregister', as I think that sounds more
>> natural than 'deregister'.
>> 
>> Additionally, if you do continue with 'deregister' or go with
>> 'unregister' as the name though, I would suggest adding 'register' as a
>> synonym for the 'scan' sub-command to keep things reasonably
>> symmetrical.
> 
>   A look up on unregister lead me to use deregister as more appropriate.
>   Anyway I won't bother much, I will be go be suggestions, and how about
>   unscan, since scan is already there. OR how about purge.

This is a bikeshed I think I have a beautiful color suggestion for! =:^)

Seriously, the normal purpose of scanning is to record particular details 
of what was seen during the scan, based on some desired scanning criteria.

So what do you call it when you need to "forget" the information you 
scanned for?

What about simply "forget", btrfs device forget ?  That sounds the most 
natural to me, certainly far more so than the apparently freshly created 
word "unscan", tho that would certainly deliver the meaning.

And FWIW, "deregister", just.. no.  (I too would vote unregister if we're 
sticking with the register root-word, but I have a feeling that may be a 
regional/en-US preference and some other English regional variants may 
find deregister is the less terrible to their ear.  That may explain 
whatever commentary under unregister led you to go with deregister.)  
"Deregister" sounds like something a computer programmer might say to 
describe the process, but I can't imagine a "normal" person using the 
word, except possibly in the context of removing someone from the voter 
rolls (where one "registers" to vote, so "deregister" could be a a 
reasonably natural term for reversing that) or the like.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [PATCH v5 0/3] Add cli and ioctl to deregister devices

[Austin S. Hemmelgarn]

On 2017-12-07 21:17, Duncan wrote:
> Anand Jain posted on Fri, 08 Dec 2017 08:51:43 +0800 as excerpted:
> 
>> On 12/07/2017 10:52 PM, Austin S. Hemmelgarn wrote:
>>> On 2017-12-07 09:36, Anand Jain wrote:
>>>> Add ability to deregister a or all devices. I have named this sub cmd
>>>> as deregister, but I am open to your suggestions.
>>> Being a bit picky here, but from the perspective of a native speaker of
>>> American English, I would say that 'deregister' sounds rather synthetic
>>> and somewhat harsh and alien.
>>>
>>> Given that, as odd as it sounds, I think 'ignore' might be a more user
>>> friendly name for the sub-command.  It accurately describes what the
>>> command is doing (telling the kernel to ignore the device), and it's a
>>> lot less alien sounding than 'deregister'.
>>>
>>> If you're set on having it be based on the word 'register', I would
>>> suggest changing it to 'unregister', as I think that sounds more
>>> natural than 'deregister'.
>>>
>>> Additionally, if you do continue with 'deregister' or go with
>>> 'unregister' as the name though, I would suggest adding 'register' as a
>>> synonym for the 'scan' sub-command to keep things reasonably
>>> symmetrical.
>>
>>    A look up on unregister lead me to use deregister as more appropriate.
>>    Anyway I won't bother much, I will be go be suggestions, and how about
>>    unscan, since scan is already there. OR how about purge.
> 
> This is a bikeshed I think I have a beautiful color suggestion for! =:^)
> 
> Seriously, the normal purpose of scanning is to record particular details
> of what was seen during the scan, based on some desired scanning criteria.
> 
> So what do you call it when you need to "forget" the information you
> scanned for?
> 
> What about simply "forget", btrfs device forget ?  That sounds the most
> natural to me, certainly far more so than the apparently freshly created
> word "unscan", tho that would certainly deliver the meaning.
I actually like forget even better than ignore, it's more descriptive 
and a bit more obvious.  'purge' might make sense if you're always 
dumping the entire list, but sounds very absolute and dangerous (and 
almost universally has a very negative connotation).
> 
> And FWIW, "deregister", just.. no.  (I too would vote unregister if we're
> sticking with the register root-word, but I have a feeling that may be a
> regional/en-US preference and some other English regional variants may
> find deregister is the less terrible to their ear.  That may explain
> whatever commentary under unregister led you to go with deregister.)
> "Deregister" sounds like something a computer programmer might say to
> describe the process, but I can't imagine a "normal" person using the
> word, except possibly in the context of removing someone from the voter
> rolls (where one "registers" to vote, so "deregister" could be a a
> reasonably natural term for reversing that) or the like.
Actually, in that case it's usually 'unregister' as well, at least in 
American English.  'deregister' is indeed largely a programming term, 
but even then it's not unusual for people to just use 'unregister' (the 
distinction that I usually use myself is that 'unregister' refers to a 
voluntary process initiated by the entity that initially registered 
whatever it was (which is the common case, and technically what this 
is), whereas 'deregister' is usually an involuntary process triggered by 
a third party (which is rare outside of things like forced kernel module 
removal or crashes)).  It's probably worth noting that both uses are 
uncommon enough that the standard American English dictionaries in 
Thunderbird and aspell lack both words (though Thunderbird does have 
'unregistered').

As far as regional variance, I've checked with a couple of friends from 
Australia, Canada, Denmark, and the UK, and all of them also felt that 
'deregister' sounded less natural than 'unregister'.  The reality is 
that pretty much regardless of the particular regional dialect, usage 
patterns for a given negation prefix tend to be reasonably consistent, 
namely:
* de- is usually used in technical verbs and not much else (desensitize, 
desaturate, deauthorize, delineate, etc)
* un- is usually used in generic terms, including verbs, adverbs, and 
adjectives, and is often the most common choice for creating 'new' words 
by negating an existing verb, adverb, or adjective (unknown, unsightly, 
unfriendly, etc)
* anti- is used exclusively for negating nouns, traditionally for 
concepts, but more recently for any noun (antithesis, antimatter, 
antidisestablishmentarianism, etc)
* dis- is used for a handful of very specific cases usually referring to 
behavior or personality, and sometimes culture (dishonest, disingenuous, 
etc)
* non- is used almost exclusively for adjectives and adverbs, but is 
less frequent than un- (nonsensical, nonplussed, etc)
* il- rarely used, typically only used for negating something describing 
the state of an action, and almost exclusively with words that begin 
with 'l', sometimes extended to ill to add a negative connotation to an 
existing word (illogical, illegal, etc).

Re: [PATCH v5 0/3] Add cli and ioctl to deregister devices

[Anand Jain]

On 12/08/2017 09:09 PM, Austin S. Hemmelgarn wrote:
> On 2017-12-07 21:17, Duncan wrote:
>> Anand Jain posted on Fri, 08 Dec 2017 08:51:43 +0800 as excerpted:
>>
>>> On 12/07/2017 10:52 PM, Austin S. Hemmelgarn wrote:
>>>> On 2017-12-07 09:36, Anand Jain wrote:
>>>>> Add ability to deregister a or all devices. I have named this sub cmd
>>>>> as deregister, but I am open to your suggestions.
>>>> Being a bit picky here, but from the perspective of a native speaker of
>>>> American English, I would say that 'deregister' sounds rather synthetic
>>>> and somewhat harsh and alien.
>>>>
>>>> Given that, as odd as it sounds, I think 'ignore' might be a more user
>>>> friendly name for the sub-command.  It accurately describes what the
>>>> command is doing (telling the kernel to ignore the device), and it's a
>>>> lot less alien sounding than 'deregister'.
>>>>
>>>> If you're set on having it be based on the word 'register', I would
>>>> suggest changing it to 'unregister', as I think that sounds more
>>>> natural than 'deregister'.
>>>>
>>>> Additionally, if you do continue with 'deregister' or go with
>>>> 'unregister' as the name though, I would suggest adding 'register' as a
>>>> synonym for the 'scan' sub-command to keep things reasonably
>>>> symmetrical.
>>>
>>>    A look up on unregister lead me to use deregister as more 
>>> appropriate.
>>>    Anyway I won't bother much, I will be go be suggestions, and how 
>>> about
>>>    unscan, since scan is already there. OR how about purge.
>>
>> This is a bikeshed I think I have a beautiful color suggestion for! =:^)
>>
>> Seriously, the normal purpose of scanning is to record particular details
>> of what was seen during the scan, based on some desired scanning 
>> criteria.
>>
>> So what do you call it when you need to "forget" the information you
>> scanned for?
>>
>> What about simply "forget", btrfs device forget ?  That sounds the most
>> natural to me, certainly far more so than the apparently freshly created
>> word "unscan", tho that would certainly deliver the meaning.
> I actually like forget even better than ignore, it's more descriptive 
> and a bit more obvious.  'purge' might make sense if you're always 
> dumping the entire list, but sounds very absolute and dangerous (and 
> almost universally has a very negative connotation).
>>
>> And FWIW, "deregister", just.. no.  (I too would vote unregister if we're
>> sticking with the register root-word, but I have a feeling that may be a
>> regional/en-US preference and some other English regional variants may
>> find deregister is the less terrible to their ear.  That may explain
>> whatever commentary under unregister led you to go with deregister.)
>> "Deregister" sounds like something a computer programmer might say to
>> describe the process, but I can't imagine a "normal" person using the
>> word, except possibly in the context of removing someone from the voter
>> rolls (where one "registers" to vote, so "deregister" could be a a
>> reasonably natural term for reversing that) or the like.
> Actually, in that case it's usually 'unregister' as well, at least in 
> American English.  'deregister' is indeed largely a programming term, 
> but even then it's not unusual for people to just use 'unregister' (the 
> distinction that I usually use myself is that 'unregister' refers to a 
> voluntary process initiated by the entity that initially registered 
> whatever it was (which is the common case, and technically what this 
> is), whereas 'deregister' is usually an involuntary process triggered by 
> a third party (which is rare outside of things like forced kernel module 
> removal or crashes)).  It's probably worth noting that both uses are 
> uncommon enough that the standard American English dictionaries in 
> Thunderbird and aspell lack both words (though Thunderbird does have 
> 'unregistered').
> 
> As far as regional variance, I've checked with a couple of friends from 
> Australia, Canada, Denmark, and the UK, and all of them also felt that 
> 'deregister' sounded less natural than 'unregister'.  The reality is 
> that pretty much regardless of the particular regional dialect, usage 
> patterns for a given negation prefix tend to be reasonably consistent, 
> namely:
> * de- is usually used in technical verbs and not much else (desensitize, 
> desaturate, deauthorize, delineate, etc)
> * un- is usually used in generic terms, including verbs, adverbs, and 
> adjectives, and is often the most common choice for creating 'new' words 
> by negating an existing verb, adverb, or adjective (unknown, unsightly, 
> unfriendly, etc)
> * anti- is used exclusively for negating nouns, traditionally for 
> concepts, but more recently for any noun (antithesis, antimatter, 
> antidisestablishmentarianism, etc)
> * dis- is used for a handful of very specific cases usually referring to 
> behavior or personality, and sometimes culture (dishonest, disingenuous, 
> etc)
> * non- is used almost exclusively for adjectives and adverbs, but is 
> less frequent than un- (nonsensical, nonplussed, etc)
> * il- rarely used, typically only used for negating something describing 
> the state of an action, and almost exclusively with words that begin 
> with 'l', sometimes extended to ill to add a negative connotation to an 
> existing word (illogical, illegal, etc).

  Quite a lot of info. Thanks. I shall use 'forget' for now. I think 
there was some concern about using 'ignore' as well, as it sounds like 
ignoring the error or something like that.

Thanks, Anand

> -- 
> 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