Re: [PATCH] btrfs: cancel scrub/replace if the user space process receive SIGKILL.

[David Sterba <dsterba@suse.cz>]

On Wed, Aug 06, 2014 at 05:34:22PM +0800, Qu Wenruo wrote:
> When impatient sysadmin is tired of waiting background running btrfs
> scrub/replace and send SIGKILL to btrfs process, unlike
> SIGINT/SIGTERM which can be caught by user space program and cancel the
> scrub work, user space program will continue running until ioctl exits.

I don't understand why it's needed to add another way to cancel scrub.
Does it mean that 'btrfs scrub cancel' is not sufficient? It cancels
both foreground and background scrub.  Same for dev-replace, it has the
cancel subcommand.

Sending KILL signal to some random process is not the right way, how can
the admin know to which filesystem the process belongs?

> To keep it consistent with the behavior of btrfs-progs, which cancels
> the work when SIGINT is received, this patch will make scrub routine to
> check SIGKILL pending of current task and cancel the work if SIGKILL is
> already pending.

The foreground scrub starts a separate process and then wait()s. If you
want to catch a SIGINT, then change it to a loop that checks for if the
forked process exited or if Ctrl-c was pressed.

The dev-replace can be started without a userspace process via
kthread_run from btrfs_dev_replace_continue_on_mount, and sending
signals to kernel processes requires some caution. For one, the signals
have to be explicitly allowed. But before that I'd like to better
understand where the SIGKILL is unavoidable.

Thanks.