linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.com
Cc: Marcos Paulo de Souza <marcos.souza.org@gmail.com>,
	linux-btrfs@vger.kernel.org, mpdesouza@suse.com
Subject: Re: [PATCH btrfs-progs 0/2] balance: check balance errors on background
Date: Thu, 31 Oct 2019 18:00:35 +0800	[thread overview]
Message-ID: <87bc3923-8cda-4bcf-a3e7-fa6204c71d5e@oracle.com> (raw)
In-Reply-To: <20191030233641.30123-1-marcos.souza.org@gmail.com>

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(-)
> 


  parent reply	other threads:[~2019-10-31 10:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-30 23:36 [PATCH btrfs-progs 0/2] balance: check balance errors on background Marcos Paulo de Souza
2019-10-30 23:36 ` [PATCH btrfs-progs 1/2] btrfs-progs: balance: Don't set stderr to /dev/null on balance_start Marcos Paulo de Souza
2019-10-30 23:36 ` [PATCH btrfs-progs 2/2] btrfs-progs: balance: Verify EINPROGRESS on background balance Marcos Paulo de Souza
2019-10-31 10:00 ` Anand Jain [this message]
2019-11-15 12:18   ` [PATCH btrfs-progs 0/2] balance: check balance errors on background David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bc3923-8cda-4bcf-a3e7-fa6204c71d5e@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=marcos.souza.org@gmail.com \
    --cc=mpdesouza@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).