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. -- Chris Murphy -- 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
