[0/3] btrfs-progs: rescue: Add create-control-device subcommand

Message

Daniel Xu Oct. 29, 2020, 11:17 p.m. UTC

This patchset adds a new `btrfs rescue create-control-device` subcommand
that acts as a convenient way to invoke:

	# mknod --mode=600 c 10 234 /dev/btrfs-control

on systems that don't have `mknod` installed or when you're lazy.

Link: https://github.com/kdave/btrfs-progs/issues/223

Daniel Xu (3):
  btrfs-progs: rescue: Add create-control-device subcommand
  btrfs-progs: bash: Update completion script with create-control-device
  btrfs-progs: rescue: Update docs with create-control-device

 Documentation/btrfs-man5.asciidoc   |  8 ++++++-
 Documentation/btrfs-rescue.asciidoc |  5 +++++
 btrfs-completion                    |  2 +-
 cmds/rescue.c                       | 35 +++++++++++++++++++++++++++++
 4 files changed, 48 insertions(+), 2 deletions(-)

--
2.26.2

Comments

Josef Bacik Nov. 13, 2020, 8:34 p.m. UTC | #1

On 10/29/20 7:17 PM, Daniel Xu wrote:
> This patchset adds a new `btrfs rescue create-control-device` subcommand
> that acts as a convenient way to invoke:
> 
> 	# mknod --mode=600 c 10 234 /dev/btrfs-control
> 
> on systems that don't have `mknod` installed or when you're lazy.
> 
> Link: https://github.com/kdave/btrfs-progs/issues/223

Reviewed-by: Josef Bacik <[e-mail]>

Thanks,

Josef

David Sterba Feb. 19, 2021, 2:48 p.m. UTC | #2

On Thu, Oct 29, 2020 at 04:17:35PM -0700, Daniel Xu wrote:
> This patchset adds a new `btrfs rescue create-control-device` subcommand
> that acts as a convenient way to invoke:
> 
> 	# mknod --mode=600 c 10 234 /dev/btrfs-control
> 
> on systems that don't have `mknod` installed or when you're lazy.

Well, I don't think the part 'lazy' applies.

The whole thing with the control device is simpler that I originally
thought. On a system without loaded btrfs module there's no
/dev/btrfs-control. This is correct because the device node is created
at load time or when btrfs_interface_init is called.

Creating just the device node makes no sense because there's nothing
handling it. Once module is loaded it appears and works as expected.

The only case where the rescue command makes sense is when the module is
loaded, device node creatd and then manually deleted. This is possible
but highly unlikely. For that reason the rescue command still has some
sense but the reasoning needs to reflect how it's related to the module
status.

As this is docs update only, I'll fix that myself, no need to resend.