All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH v23.2 3/4] xfs: log the AGI/AGF buffers when rolling transactions during an AG repair
Date: Tue, 1 Nov 2022 08:17:36 +1100	[thread overview]
Message-ID: <20221031211736.GM3600936@dread.disaster.area> (raw)
In-Reply-To: <Y2APIan1VaLglNzY@magnolia>

On Mon, Oct 31, 2022 at 11:08:33AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> Currently, the only way to lock an allocation group is to hold the AGI
> and AGF buffers.  If a repair needs to roll the transaction while
> repairing some AG metadata, it maintains that lock by holding the two
> buffers across the transaction roll and joins them afterwards.
> 
> However, repair is not like other parts of XFS that employ the bhold -
> roll - bjoin sequence because it's possible that the AGI or AGF buffers
> are not actually dirty before the roll.  This presents two problems --
> First, we need to redirty those buffers to keep them moving along in the
> log to avoid pinning the log tail.  Second, a clean buffer log item can
> detach from the buffer.  If this happens, the buffer type state is
> discarded along with the bli and must be reattached before the next time
> the buffer is logged.   If it is not, the logging code will complain and
> log recovery will not work properly.
> 
> An earlier version of this patch tried to fix the second problem by
> re-setting the buffer type in the bli after joining the buffer to the
> new transaction, but that looked weird and didn't solve the first
> problem.  Instead, solve both problems by logging the buffer before
> rolling the transaction.
> 
> Signed-off-by: Darrick J. Wong <djwong@kernel.org>

I guess this is fine as long as it is confined to the scrub code;
if we need to hold clean buffers across transaction rolls in other
code we really need to sort out the BLI life cycle issues that this
currently exposes.

Reviewed-by: Dave Chinner <dchinner@redhat.com>
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2022-10-31 21:18 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-02 18:19 [PATCHSET v23.1 0/4] xfs: fix handling of AG[IF] header buffers during scrub Darrick J. Wong
2022-10-02 18:19 ` [PATCH 2/4] xfs: don't track the AGFL buffer in the scrub AG context Darrick J. Wong
2022-10-13 22:32   ` Dave Chinner
2022-10-02 18:19 ` [PATCH 3/4] xfs: set the buffer type after holding the AG[IF] across trans_roll Darrick J. Wong
2022-10-13 22:25   ` Dave Chinner
2022-10-13 23:19     ` Darrick J. Wong
2022-10-14  1:28       ` Dave Chinner
2022-10-24  4:16         ` Darrick J. Wong
2022-10-31 18:08   ` [PATCH v23.2 3/4] xfs: log the AGI/AGF buffers when rolling transactions during an AG repair Darrick J. Wong
2022-10-31 21:17     ` Dave Chinner [this message]
2022-10-02 18:19 ` [PATCH 1/4] xfs: fully initialize xfs_da_args in xchk_directory_blocks Darrick J. Wong
2022-10-13 22:33   ` Dave Chinner
2022-10-02 18:19 ` [PATCH 4/4] xfs: make AGFL repair function avoid crosslinked blocks Darrick J. Wong
2022-10-13 22:35   ` Dave Chinner

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=20221031211736.GM3600936@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=linux-xfs@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.