From: Chris Murphy <lists@colorremedies.com>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: Chris Murphy <lists@colorremedies.com>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: systemd KillUserProcesses=yes and btrfs scrub
Date: Mon, 1 Aug 2016 10:19:01 -0600 [thread overview]
Message-ID: <CAJCQCtRgmfWVf9YB2=fVLDSRhm4-t7W+YHBabBaBsBZeSiDU1Q@mail.gmail.com> (raw)
In-Reply-To: <a582564a-e991-dd35-721f-31c807a24929@gmail.com>
On Mon, Aug 1, 2016 at 10:08 AM, Austin S. Hemmelgarn
<ahferroin7@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.
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.
> Replace was implemented the way scrub should have been. It's done entirely
> in the kernel, and the userspace tools just start, stop and check status.
> We should just get rid of the whole scrub state file crap and have a way to
> query the last scrub status directly from the FS. That would fix this
> particular issue, and make scrub more consistent with everything else (and
> solve the stale scrub status bug too).
OK, I'll update the bug report.
--
Chris Murphy
next prev parent reply other threads:[~2016-08-01 16:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-30 20:02 systemd KillUserProcesses=yes and btrfs scrub Chris Murphy
2016-07-31 0:29 ` Chris Murphy
2016-08-01 12:44 ` Austin S. Hemmelgarn
2016-08-01 15:46 ` Chris Murphy
2016-08-01 15:52 ` Chris Murphy
2016-08-01 16:08 ` Austin S. Hemmelgarn
2016-08-01 16:19 ` Chris Murphy [this message]
2016-08-01 16:22 ` Chris Murphy
2016-08-01 16:58 ` Austin S. Hemmelgarn
2016-08-01 17:15 ` Chris Murphy
2016-08-01 17:19 ` Austin S. Hemmelgarn
2016-08-01 17:47 ` Chris Murphy
2016-08-01 18:00 ` Chris Murphy
2016-08-01 18:43 ` Chris Murphy
2016-07-31 10:56 ` Gabriel C
2016-07-31 16:58 ` Chris Murphy
2016-08-01 3:33 ` Duncan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJCQCtRgmfWVf9YB2=fVLDSRhm4-t7W+YHBabBaBsBZeSiDU1Q@mail.gmail.com' \
--to=lists@colorremedies.com \
--cc=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).