All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: fdmanana@kernel.org
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: reduce the scope of the tree log mutex during transaction commit
Date: Wed, 10 Nov 2021 09:05:42 -0500	[thread overview]
Message-ID: <YYvRtuATuj/ASxDm@localhost.localdomain> (raw)
In-Reply-To: <f9f76a38d5a908d438816a778a7d55764a6360f3.1636538581.git.fdmanana@suse.com>

On Wed, Nov 10, 2021 at 10:05:21AM +0000, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
> 
> In the transaction commit path we are acquiring the tree log mutex too
> early and we have a stale comment because:
> 
> 1) It mentions a function named btrfs_commit_tree_roots(), which does not
>    exists anymore, it was the old name of commit_cowonly_roots(), renamed
>    a very long time ago by commit 5d4f98a28c7d33 ("Btrfs: Mixed back
>    reference  (FORWARD ROLLING FORMAT CHANGE)"));
> 
> 2) It mentions that we need to acquire the tree log mutex at that point
>    to ensure we have no running log writers. That is not correct anymore,
>    for many years at least, since we are guaranteed that we do not have
>    any log writers at that point simply because we have set the state of
>    the transaction to TRANS_STATE_COMMIT_DOING and have waited for all
>    writers to complete - meaning no one can log until we change the state
>    of the transaction to TRANS_STATE_UNBLOCKED. Any attempts to join the
>    transaction or start a new one will block until we do that state
>    transition;
> 
> 3) The comment mentions a "trans mutex" which doesn't exists since 2011,
>    commit a4abeea41adf ("Btrfs: kill trans_mutex") removed it;
> 
> 4) The current use of the tree log mutex is to ensure proper serialization
>    of super block writes - if someone started a new transaction and uses it
>    for logging, it will wait for the previous transaction to write its
>    super block before writing the super block when attempting to sync the
>    log.
> 
> So acquire the tree log mutex only when it's absolutely needed, before
> setting the transaction state to TRANS_STATE_UNBLOCKED, fix and move the
> stale comment, add some assertions and new comments where appropriate.
> 
> Also, this has no effect on concurrency or performance, since the new
> start of the critical section is still when the transaction is in the
> state TRANS_STATE_COMMIT_DOING.
> 
> Signed-off-by: Filipe Manana <fdmanana@suse.com>

Reviewed-by: Josef Bacik <josef@toxicpanda.com>

Thanks,

Josef

  reply	other threads:[~2021-11-10 14:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-10 10:05 [PATCH] btrfs: reduce the scope of the tree log mutex during transaction commit fdmanana
2021-11-10 14:05 ` Josef Bacik [this message]
2021-11-10 16:34 ` 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=YYvRtuATuj/ASxDm@localhost.localdomain \
    --to=josef@toxicpanda.com \
    --cc=fdmanana@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.