-------- Original Message --------
Subject: Re: [PATCH] btrfs: cancel scrub/replace if the user space
process receive SIGKILL.
From: David Sterba <dsterba@xxxxxxx>
To: Qu Wenruo <quwenruo@xxxxxxxxxxxxxx>
Date: 2014年09月02日 19:05
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.
Yes, 'scrub cacnel' is sufficient and it's what userspace calls when
catching SIGINT.
I sent the user-space patch to fix the 'dev-replace cancel' signal
handling and then consider
since SIGKILL can't be caught, it can't be handle in user-space so I
then sent the kernel patch to handle it.
But if user-space can handle SIGINT correctly, the SIGKILL won't be
sent, so the kernel patch can be ignored.
Thanks,
Qu
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
