Re: Is "btrfs balance start" truly asynchronous?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-06-21 07:33, Hugo Mills wrote:
> On Tue, Jun 21, 2016 at 07:24:24AM -0400, Austin S. Hemmelgarn wrote:
>> On 2016-06-21 04:55, Duncan wrote:
>>> Dmitry Katsubo posted on Mon, 20 Jun 2016 18:33:54 +0200 as excerpted:
>>>
>>>> Dear btfs community,
>>>>
>>>> I have added a drive to existing raid1 btrfs volume and decided to
>>>> perform balancing so that data distributes "fairly" among drives. I have
>>>> started "btrfs balance start", but it stalled for about 5-10 minutes
>>>> intensively doing the work. After that time it has printed something
>>>> like "had to relocate 50 chunks" and exited. According to drive I/O,
>>>> "btrfs balance" did most (if not all) of the work, so after it has
>>>> exited the job was done.
>>>>
>>>> Shouldn't "btrfs balance start" do the operation in the background?
>>>
>> >From the btrfs-balance (8) manpage (from btrfs-progs-4.5.3):
>>>
>>> start [options] <path>
>>>    start the balance operation according to the specified filters,
>>>    no filters will rewrite the entire filesystem. The process runs
>>>    in the foreground.
>>>
>>>
>>> So the balance start operation runs in the foreground, but as explained
>>> elsewhere in the manpage, the balance is interruptible by unmount and
>>> will automatically restart after a remount.  It can also be paused and
>>> resumed or canceled with the appropriate btrfs balance subcommands.
>>>
>> FWIW, there was some talk a while back about possibly providing an
>> option to run balance in the background.  If I end up finding the
>> time, I may write a patch for this (userland only, I'm not
>> interested in mucking around with the kernel side of things, and
>> it's fully possible to do this just using libc functions), as it's
>> something I'd rather like to have myself, as the current method of
>> using job control in a shell doesn't really work in some
>> circumstances (for example, you can't easily start a balance on a
>> remote system via a ssh command, which is the specific use case I
>> have).
>
>    There's quite a bit of infrastructure in the userspace tools to
> deal with managing an asynchronous scrub. It would probably be worth
> looking at that in the first instance to see if it can be reused for
> balance.
Yeah, but we've also already got most of what's needed though for an 
asynchronous balance.  The kernel itself functionally mutexes balances 
(at least, I'm pretty certain it does), we already store state in the 
filesystem itself (so that it can be auto-resumed on remount), and we 
already have commands for pausing, resuming, canceling, and checking 
status.  The only thing that appears to be missing is the ability to 
have the balance backgrounded by the tools themselves instead of needing 
POSIX sh job control or something to daemonize it.

The scrub design works, but the whole state file thing has some rather 
irritating side effects and other implications, and developed out of 
requirements that aren't present for balance (it might be nice to check 
how many chunks actually got balanced after the fact, but it's not 
absolutely necessary).