public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Boris Burkov <boris@bur.io>, Chris Mason <clm@fb.com>,
	Josef Bacik <josef@toxicpanda.com>,
	David Sterba <dsterba@suse.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH RFC] btrfs: change commit txn to end txn in subvol_setflags ioctl
Date: Wed, 5 Aug 2020 06:48:57 +0800	[thread overview]
Message-ID: <86c25213-e961-790e-dc27-8c2a9aa118c1@gmx.com> (raw)
In-Reply-To: <20200804175516.2511704-1-boris@bur.io>


[-- Attachment #1.1: Type: text/plain, Size: 2527 bytes --]



On 2020/8/5 上午1:55, Boris Burkov wrote:
> Currently, btrfs_ioctl_subvol_setflags forces a btrfs_commit_transaction
> while holding subvol_sem. As a result, we have seen workloads where
> calling `btrfs property set -ts <subvol> ro false` hangs waiting for a
> legitimately slow commit. This gets even worse if the workload tries to
> set flags on multiple subvolumes and the ioctls pile up on subvol_sem.
> 
> Change the commit to a btrfs_end_transaction so that the ioctl can
> return in a timely fashion and piggy back on a later commit.
> 
> Signed-off-by: Boris Burkov <boris@bur.io>
> ---
>  fs/btrfs/ioctl.c       | 2 +-
>  fs/btrfs/transaction.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index bd3511c5ca81..3ae484768ce7 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -1985,7 +1985,7 @@ static noinline int btrfs_ioctl_subvol_setflags(struct file *file,
>  		goto out_reset;
>  	}
>  
> -	ret = btrfs_commit_transaction(trans);
> +	ret = btrfs_end_transaction(trans);

This means the setflag is not committed to disk, and if a powerloss
happens before a transaction commit, then the setflag operation just get
lost.

This means, previously if this ioctl returns, users can expect that the
flag is always set no matter what, but now there is no guarantee.

Personally I'm not sure if we really want that operation to be committed
to disk.
Maybe that transaction commit can be initialized in user space, so for
multiple setflags, we only commit once, thus saves a lot of time.

Thanks,
Qu

>  
>  out_reset:
>  	if (ret)
> diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
> index 20c6ac1a5de7..1dc44209c2ae 100644
> --- a/fs/btrfs/transaction.c
> +++ b/fs/btrfs/transaction.c
> @@ -47,7 +47,7 @@
>   * | Will wait for previous running transaction to completely finish if there
>   * | is one
>   * |
> - * | Then one of the following happes:
> + * | Then one of the following happens:
>   * | - Wait for all other trans handle holders to release.
>   * |   The btrfs_commit_transaction() caller will do the commit work.
>   * | - Wait for current transaction to be committed by others.
> @@ -60,7 +60,7 @@
>   * |
>   * | To next stage:
>   * |  Caller is chosen to commit transaction N, and all other trans handle
> - * |  haven been released.
> + * |  have been released.
>   * V
>   * Transaction N [[TRANS_STATE_COMMIT_DOING]]
>   * |
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-08-04 22:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-04 17:55 [PATCH RFC] btrfs: change commit txn to end txn in subvol_setflags ioctl Boris Burkov
2020-08-04 22:48 ` Qu Wenruo [this message]
2020-08-04 23:08   ` Josef Bacik
2020-08-05 13:40     ` Martin Raiber
2020-08-07 20:45       ` Boris Burkov
2020-08-10 18:05         ` Martin Raiber
2020-08-25 20:23           ` Boris Burkov
2020-08-26 14:23 ` Josef Bacik

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=86c25213-e961-790e-dc27-8c2a9aa118c1@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=boris@bur.io \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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