[PATCH btrfs-progs 0/2] balance: check balance errors on background

[PATCH btrfs-progs 0/2] balance: check balance errors on background

[Marcos Paulo de Souza]

From: Marcos Paulo de Souza <mpdesouza@suse.com>

The first patch removes the close/open operation of stderr, so we can receive
errors of balance when starting in the background.

The second patch waits up to three seconds after started the balance process, to
check is some problem happened to the balance process. This is done only when
the user issues the "balance start" in background mode.

This was tested by issuing running "btrfs balance start --background
--full-balance <path>", when the balance started, issue the same command again
in the same terminal:

# ./btrfs balance start --background --full-balance /mnt
# ./btrfs balance start --background --full-balance /mnt
ERROR: error during balancing '/mnt': Operation now in progress

These two patches together fixes the issue 167[1].

Please review,
Thanks.

[1]: https://github.com/kdave/btrfs-progs/issues/167

Marcos Paulo de Souza (2):
  btrfs-progs: balance: Don't set stderr to /dev/null on balance_start
  btrfs-progs: balance: Verify EINPROGRESS on background balance

 cmds/balance.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

-- 
2.23.0

[PATCH btrfs-progs 1/2] btrfs-progs: balance: Don't set stderr to /dev/null on balance_start

[Marcos Paulo de Souza]

From: Marcos Paulo de Souza <mpdesouza@suse.com>

Remove the close/open calls in order to receive the error messages when
starting balance in the background.

Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
---
 cmds/balance.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/cmds/balance.c b/cmds/balance.c
index 32830002..f0394a2e 100644
--- a/cmds/balance.c
+++ b/cmds/balance.c
@@ -659,10 +659,8 @@ static int cmd_balance_start(const struct cmd_struct *cmd,
 				i = chdir("/");
 				close(0);
 				close(1);
-				close(2);
 				open("/dev/null", O_RDONLY);
 				open("/dev/null", O_WRONLY);
-				open("/dev/null", O_WRONLY);
 				break;
 			default:
 				exit(0);
-- 
2.23.0

[PATCH btrfs-progs 2/2] btrfs-progs: balance: Verify EINPROGRESS on background balance

[Marcos Paulo de Souza]

From: Marcos Paulo de Souza <mpdesouza@suse.com>

Introduce a sleep of 3 seconds after triggering balance to check if
isn't there another balance already being executed.

Fix: #167

Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
---
 cmds/balance.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/cmds/balance.c b/cmds/balance.c
index f0394a2e..2accc102 100644
--- a/cmds/balance.c
+++ b/cmds/balance.c
@@ -22,6 +22,7 @@
 #include <sys/ioctl.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#include <sys/wait.h>
 #include <fcntl.h>
 #include <errno.h>
 
@@ -507,6 +508,7 @@ static int cmd_balance_start(const struct cmd_struct *cmd,
 	int force = 0;
 	int verbose = 0;
 	int background = 0;
+	pid_t child;
 	unsigned start_flags = 0;
 	int i;
 
@@ -639,13 +641,13 @@ static int cmd_balance_start(const struct cmd_struct *cmd,
 	if (verbose)
 		dump_ioctl_balance_args(&args);
 	if (background) {
-		switch (fork()) {
+		switch (child = fork()) {
 		case (-1):
 			error("unable to fork to run balance in background");
 			return 1;
 		case (0):
 			setsid();
-			switch(fork()) {
+			switch(child = fork()) {
 			case (-1):
 				error(
 				"unable to fork to run balance in background");
@@ -663,10 +665,21 @@ static int cmd_balance_start(const struct cmd_struct *cmd,
 				open("/dev/null", O_WRONLY);
 				break;
 			default:
+				/* wait up to three seconds to check if balance
+				 * isn't already running */
+				i = 0;
+				while (waitpid(child, NULL, WNOHANG) == 0 && i++ < 3)
+					sleep(1);
+
+				/* ensure that any error message from
+				 * do_balance is flushed */
+				fflush(stderr);
 				exit(0);
 			}
 			break;
 		default:
+			/* Wait for the first child to return */
+			waitpid(child, NULL, 0);
 			exit(0);
 		}
 	}
-- 
2.23.0

Re: [PATCH btrfs-progs 0/2] balance: check balance errors on background

[Anand Jain]

On 10/31/19 7:36 AM, Marcos Paulo de Souza wrote:
> From: Marcos Paulo de Souza <mpdesouza@suse.com>
> 
> The first patch removes the close/open operation of stderr, so we can receive
> errors of balance when starting in the background.
> 
> The second patch waits up to three seconds after started the balance process, to
> check is some problem happened to the balance process. This is done only when
> the user issues the "balance start" in background mode.
> 
> This was tested by issuing running "btrfs balance start --background
> --full-balance <path>", when the balance started, issue the same command again
> in the same terminal:
> 
> # ./btrfs balance start --background --full-balance /mnt
> # ./btrfs balance start --background --full-balance /mnt
> ERROR: error during balancing '/mnt': Operation now in progress
> 
> These two patches together fixes the issue 167[1].
> 
> Please review,
> Thanks.
> 
> [1]: https://github.com/kdave/btrfs-progs/issues/167


David,

-----
(To fix this, the parent process should wait a bit if the forked 
background process still runs and report errors otherwise. There are no 
blocking calls when the 2nd ioctl is called, so a few seconds should be 
enough.)
-----

  This approach might work in most of the cases. However user thread
  waiting for 3 sec is not a deterministic way to find if the balance
  was started successfully in the kernel. IMO.

  Instead can we use the balance start ioctl to spin a kthread
  to run the actual balance that is __btrfs_balance(). With means
  until call to __btrfs_balance() we shall use ioctl-thread and
  to spin up kthread to run __btrfs_balance() and return the ioctl
  thread with the interim status
  (So for the --no-background user thread has to monitor the
  balance status using the balance progress ioctl and return when
  the status becomes completed and also it should call balance control
  ioctl if the received sigint).

  We do use kthread for balance, if mount thread has to resume the
  balance. so its a kind of extension to it.

  But in the view of the backward btrfs-progs compatibility (that is new
  kernel with old progs) it looks like we need a new balance-ioctl
  altogether, but the question is if its too much infrastructure changes,
  which otherwise might have worked fairly well with a 3 sec delay? What
  do you think? I think its a good idea to fix it in the right way.


Thanks, Anand

> Marcos Paulo de Souza (2):
>    btrfs-progs: balance: Don't set stderr to /dev/null on balance_start
>    btrfs-progs: balance: Verify EINPROGRESS on background balance
> 
>   cmds/balance.c | 19 +++++++++++++++----
>   1 file changed, 15 insertions(+), 4 deletions(-)
> 

Re: [PATCH btrfs-progs 0/2] balance: check balance errors on background

[David Sterba]

On Thu, Oct 31, 2019 at 06:00:35PM +0800, Anand Jain wrote:
> On 10/31/19 7:36 AM, Marcos Paulo de Souza wrote:
> > From: Marcos Paulo de Souza <mpdesouza@suse.com>
> > 
> > The first patch removes the close/open operation of stderr, so we can receive
> > errors of balance when starting in the background.
> > 
> > The second patch waits up to three seconds after started the balance process, to
> > check is some problem happened to the balance process. This is done only when
> > the user issues the "balance start" in background mode.
> > 
> > This was tested by issuing running "btrfs balance start --background
> > --full-balance <path>", when the balance started, issue the same command again
> > in the same terminal:
> > 
> > # ./btrfs balance start --background --full-balance /mnt
> > # ./btrfs balance start --background --full-balance /mnt
> > ERROR: error during balancing '/mnt': Operation now in progress
> > 
> > These two patches together fixes the issue 167[1].
> > 
> > Please review,
> > Thanks.
> > 
> > [1]: https://github.com/kdave/btrfs-progs/issues/167
> 
> 
> David,
> 
> -----
> (To fix this, the parent process should wait a bit if the forked 
> background process still runs and report errors otherwise. There are no 
> blocking calls when the 2nd ioctl is called, so a few seconds should be 
> enough.)
> -----
> 
>   This approach might work in most of the cases. However user thread
>   waiting for 3 sec is not a deterministic way to find if the balance
>   was started successfully in the kernel. IMO.

Yes, that's right, it's the simplest thing to implement right now.

>   Instead can we use the balance start ioctl to spin a kthread
>   to run the actual balance that is __btrfs_balance(). With means
>   until call to __btrfs_balance() we shall use ioctl-thread and
>   to spin up kthread to run __btrfs_balance() and return the ioctl
>   thread with the interim status
>   (So for the --no-background user thread has to monitor the
>   balance status using the balance progress ioctl and return when
>   the status becomes completed and also it should call balance control
>   ioctl if the received sigint).
> 
>   We do use kthread for balance, if mount thread has to resume the
>   balance. so its a kind of extension to it.
> 
>   But in the view of the backward btrfs-progs compatibility (that is new
>   kernel with old progs) it looks like we need a new balance-ioctl
>   altogether, but the question is if its too much infrastructure changes,
>   which otherwise might have worked fairly well with a 3 sec delay? What
>   do you think? I think its a good idea to fix it in the right way.

The balance ioctl could start a kthread, we don't need to do a new ioctl
but just extend flags passed to BTRFS_IOC_BALANCE_V2.

As the current --background option creates a userspace process, this is
something we can't silently change to a kernel thread. So this will
probably need a new option but otherwise I don't see any other problems.

Reporting the status is done in the same way using the ioctl
BTRFS_IOC_BALANCE_PROGRESS .

The 3 second wait is not 100% reliable, we can potentially make it a bit
more reliable if the timeout starts right before the other process
starts the ioctl. To minimize effects of activity in the rest of the
system. This could be done in a simple way by a pipe that signals from
the child to the parent that the ioctl is going to be called next.