On Sat, Jul 30, 2016 at 10:44 AM, Chris Adams <linux@xxxxxxxxxxx> wrote: > Once upon a time, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> said: >> On Fri, Jul 29, 2016 at 2:36 PM, Chris Adams <linux@xxxxxxxxxxx> wrote: >> > The actual work of pvmove is not done by the command you run; that sets >> > it up and it is run in the background (by a kernel thread). All the >> > command you run does then is periodically check and print a percentage >> > done. >> >> It's the same with btrfs balance and scrub. It may be the operation >> completes by kernel code, but with user space detached from the kill, >> the status/statistics are lost. > > I don't know about btrfs, but with LVM, nothing is lost. You can run > "pvmove" at any time to continue to show the status. I see the same behavior. I'm not sure what the user space tool reattaches to, something in sysfs or lvmetad? > And we're talking about KillUserProcesses; logging out _already_ killed > the pvmove command. Nothing has changed. It doesn't go to the background by default, where btrfs scrub, balance, and replace do. At least with scrub, the process continues to work when KillUserProcesses=no and I logout; where if it's set to yes, the process goes from status S to Z, and shortly after that the kernel threads stop working also. I can't actually tell if this is just an accounting problem, or if the scrub really is interrupted. Guess we'll see what btrfs upstream thinks about it, but the idea that Btrfs users are going to know their scrubs fail due to this feature is flawed. There's zero indication why the process dies, and there's no way to get more information in the journal to hint at why it dies. Plus it's inconsistent. Neither btrfs balance nor replace have this problem, those processes continue to run with status D and R until they complete. systemd KillUserProcesses=yes and btrfs scrub https://bugzilla.kernel.org/show_bug.cgi?id=150781 Anyway, the feature still strikes me as merely exchanging problems we know for problems we don't know. It's rather a lot like punting. -- Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
