Bug 150781
Summary: | systemd KillUserProcesses=yes and btrfs scrub | ||
---|---|---|---|
Product: | File System | Reporter: | Chris Murphy (bugzilla) |
Component: | btrfs | Assignee: | Josef Bacik (josef) |
Status: | NEW --- | ||
Severity: | normal | CC: | dsterba |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 4.7.0-0.rc7.git3.1.fc25.x86_64 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Chris Murphy
2016-07-30 19:59:24 UTC
This has been supported for a while so it's not necessary to use systemd v230, just make sure KillUserProcesses=yes to reproduce. systemd v230 is the first to default to KillUserProcesses=yes. Looks like scrub user space code is doing the accounting, so when it goes status Z on logout, it stops the accounting. Subsequent status checks are stale for the entire duration of the continuing scrub done by the kernel, which proceeds unimpeded. Once the kernel scrub is done, btrfs scrub status reports interruption which actually means the user space accounting was interrupted, not the scrub itself. Fix needed is for user space scrub code to just issue commands, and poll for status, rather than doing the statistical accounting work. This already appears to be the case for btrfs replace, and is also consistent with how LVM tools work for similar operations like pvmove and lvchange --syncaction. https://mail-archive.com/linux-btrfs@vger.kernel.org/msg56259.html |