From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f65.google.com ([209.85.214.65]:35633 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754173AbcHAQ6v (ORCPT ); Mon, 1 Aug 2016 12:58:51 -0400 Received: by mail-it0-f65.google.com with SMTP id f6so12184236ith.2 for ; Mon, 01 Aug 2016 09:58:42 -0700 (PDT) Subject: Re: systemd KillUserProcesses=yes and btrfs scrub To: Chris Murphy References: Cc: Btrfs BTRFS From: "Austin S. Hemmelgarn" Message-ID: Date: Mon, 1 Aug 2016 12:58:35 -0400 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 2016-08-01 12:19, Chris Murphy wrote: > On Mon, Aug 1, 2016 at 10:08 AM, Austin S. Hemmelgarn > 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). > > >> 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. >