On 2016-08-01 13:15, Chris Murphy wrote:
On Mon, Aug 1, 2016 at 10:58 AM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
On 2016-08-01 12:19, Chris Murphy wrote:
On Mon, Aug 1, 2016 at 10:08 AM, Austin S. Hemmelgarn
<ahferro...@gmail.com> wrote:
MD and DM RAID handle this by starting kernel threads to do the scrub.
They
then store the info about the scrub in the array itself, so you can query
it
externally. If you watch, neither of those commands runs longer than it
takes to start the operation, so there's nothing for systemd to kill.
pvmove continues to run and report progress so it can be killed off,
but it only polls for statistics, it's not actually recording them. So
even though it gets killed, subsequent pvmove command shows correct
statistics.
Because all that the pvmove command is doing is polling for statistics. It
actually works kind of like a scrub, all the actual work is done in the
kernel, the userspace component just handles reporting. The difference is
that the move operation is accounted and mutexed in the kernel itself,
instead of userspace like scrub does. This model is actually essentially
what I think scrub (and balance for that matter) should look like, and if
implemented right, we could actually store scrub results in the FS itself
(that is, in the metadata, not in special files or anything like that).
So that makes me wonder how btrfs device add and remove will behave,
if issued in a DE which is then logged out of. Those commands do not
return to prompt until they complete.
They work via balance, so they should behave the same as a balance command,
which means it will likely run part way then get cancelled because of the
SIGTERM to the userspace component (assuming of course that it is still
running when you log out).
I've been using balance with &, and when I logout, the btrfs command
continues to flip between status D and R, just like before logout and
it appears to complete. I still get status messages of the balance
after logout, in kernel messages.
Interesting, maybe balance is explicitly white-listed? Either that, or
it just ignores whatever signal systemd uses to kill stuff in this
context (I initially thought SIGTERM, but SIGHUP would make more sense
in this context), which wouldn't surprise me either.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
