All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 4/9] xfs: ensure log tail is always up to date
Date: Fri, 26 Aug 2022 16:49:17 -0700	[thread overview]
Message-ID: <Ywlb/WABtwa4BocN@magnolia> (raw)
In-Reply-To: <Ywk9pqHtrVji6mg7@magnolia>

On Fri, Aug 26, 2022 at 02:39:50PM -0700, Darrick J. Wong wrote:
> On Tue, Aug 23, 2022 at 12:18:47PM +1000, Dave Chinner wrote:
> > On Mon, Aug 22, 2022 at 05:33:19PM -0700, Darrick J. Wong wrote:
> > > On Wed, Aug 10, 2022 at 09:03:48AM +1000, Dave Chinner wrote:
> > > > From: Dave Chinner <dchinner@redhat.com>
> > > > 
> > > > Whenever we write an iclog, we call xlog_assign_tail_lsn() to update
> > > > the current tail before we write it into the iclog header. This
> > > > means we have to take the AIL lock on every iclog write just to
> > > > check if the tail of the log has moved.
> > > > 
> > > > This doesn't avoid races with log tail updates - the log tail could
> > > > move immediately after we assign the tail to the iclog header and
> > > > hence by the time the iclog reaches stable storage the tail LSN has
> > > > moved forward in memory. Hence the log tail LSN in the iclog header
> > > > is really just a point in time snapshot of the current state of the
> > > > AIL.
> > > > 
> > > > With this in mind, if we simply update the in memory log->l_tail_lsn
> > > > every time it changes in the AIL, there is no need to update the in
> > > > memory value when we are writing it into an iclog - it will already
> > > > be up-to-date in memory and checking the AIL again will not change
> > > > this.
> > > 
> > > This is too subtle for me to understand -- does the codebase
> > > already update l_tail_lsn?  Does this patch make it do that?
> > 
> > tl;dr: if the AIL is empty, log->l_tail_lsn is not updated on the
> > first insert of a new item into the AILi and hence is stale.
> > xlog_state_release_iclog() currently works around that by calling
> > xlog_assign_tail_lsn() to get the tail lsn from the AIL. This change
> > makes sure log->l_tail_lsn is always up to date.
> > 
> > In more detail:
> > 
> > The tail update occurs in xfs_ail_update_finish(), but only if we
> > pass in a non-zero tail_lsn. xfs_trans_ail_update_bulk() will only
> > set a non-zero tail_lsn if it moves the log item at the tail of the
> > log (i.e. we relog the tail item and move it forwards in the AIL).
> > 
> > Hence if we pass a non-zero tail_lsn to xfs_ail_update_finish(), it
> > indicates it needs to check it against the LSN of the item currently
> > at the tail of the AIL. If the tail LSN has not changed, we do
> > nothing, if it has changed, then we call
> > xlog_assign_tail_lsn_locked() to update the log tail.
> > 
> > The problem with the current code is that if the AIL is empty when
> > we insert the first item, we've actually moved the log tail but we
> > do not update the log tail (i.e. tail_lsn is zero in this case). If
> > we then release an iclog for writing at this point in time, the tail
> > lsn it writes into the iclog header would be wrong - it does not
> > reflect the log tail as defined by the AIL and the checkpoint that
> > has just been committed.
> > 
> > Hence xlog_state_release_iclog() called xlog_assign_tail_lsn() to
> > ensure that it checked that the tail LSN it applies to the iclog
> > reflects the current state of the AIL. i.e. it checks if there is an
> > item in the AIL, and if so, grabs the tail_lsn from the AIL. This
> > works around the fact the AIL doesn't update the log tail on the
> > first insert.
> > 
> > Hence what this patch does is have xfs_trans_ail_update_bulk set
> > the tail_lsn passed to xfs_ail_update_finish() to NULLCOMMITLSN when
> > it does the first insert into the AIL. NULLCOMMITLSN is a
> > non-zero value that won't match with the LSN of items we just
> > inserted into the AIL, and hence xfs_ail_update_finish() will go an
> > update the log tail in this case.
> > 
> > Hence we close the hole when the log->l_tail_lsn is incorrect after
> > the first insert into the AIL, and hence we no longer need to update
> > the log->l_tail_lsn when reading it into the iclog header -
> > log->l_tail_lsn is always up to date, and so we can now just read it
> > in xlog_state_release_iclog() rather than having to grab the AIL
> > lock and checking the AIL to update log->l_tail_lsn with the correct
> > tail value from iclog IO submission....
> 
> Ahhh, ok, I get it now.  Thanks for the explanation.

Looks ok to me now,
Reviewed-by: Darrick J. Wong <djwong@kernel.org>

--D

> 
> --D
> 
> > Cheers,
> > 
> > Dave.
> > -- 
> > Dave Chinner
> > david@fromorbit.com

  reply	other threads:[~2022-08-26 23:49 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-09 23:03 [PATCH 0/9 v2] xfs: byte-base grant head reservation tracking Dave Chinner
2022-08-09 23:03 ` [PATCH 1/9] xfs: move and xfs_trans_committed_bulk Dave Chinner
2022-08-10 14:17   ` kernel test robot
2022-08-10 17:08   ` kernel test robot
2022-08-22 15:03   ` Darrick J. Wong
2022-09-07 13:51   ` Christoph Hellwig
2022-08-09 23:03 ` [PATCH 2/9] xfs: AIL doesn't need manual pushing Dave Chinner
2022-08-22 17:08   ` Darrick J. Wong
2022-08-23  1:51     ` Dave Chinner
2022-08-26 15:46       ` Darrick J. Wong
2022-09-07 14:01   ` Christoph Hellwig
2023-10-12  8:44     ` Christoph Hellwig
2022-08-09 23:03 ` [PATCH 3/9] xfs: background AIL push targets physical space, not grant space Dave Chinner
2022-08-22 19:00   ` Darrick J. Wong
2022-08-23  2:01     ` Dave Chinner
2022-08-26 15:47       ` Darrick J. Wong
2022-08-26 23:49         ` Darrick J. Wong
2022-09-07 14:04   ` Christoph Hellwig
2022-08-09 23:03 ` [PATCH 4/9] xfs: ensure log tail is always up to date Dave Chinner
2022-08-23  0:33   ` Darrick J. Wong
2022-08-23  2:18     ` Dave Chinner
2022-08-26 21:39       ` Darrick J. Wong
2022-08-26 23:49         ` Darrick J. Wong [this message]
2022-09-07 14:06   ` Christoph Hellwig
2022-08-09 23:03 ` [PATCH 5/9] xfs: l_last_sync_lsn is really AIL state Dave Chinner
2022-08-26 22:19   ` Darrick J. Wong
2022-09-07 14:11   ` Christoph Hellwig
2022-08-09 23:03 ` [PATCH 6/9] xfs: collapse xlog_state_set_callback in caller Dave Chinner
2022-08-26 22:20   ` Darrick J. Wong
2022-09-07 14:12   ` Christoph Hellwig
2022-08-09 23:03 ` [PATCH 7/9] xfs: track log space pinned by the AIL Dave Chinner
2022-08-26 22:39   ` Darrick J. Wong
2022-08-09 23:03 ` [PATCH 8/9] xfs: pass the full grant head to accounting functions Dave Chinner
2022-08-26 22:25   ` Darrick J. Wong
2022-08-09 23:03 ` [PATCH 9/9] xfs: grant heads track byte counts, not LSNs Dave Chinner
2022-08-26 23:45   ` Darrick J. Wong
  -- strict thread matches above, loose matches on Subject: below --
2022-12-20 23:22 [PATCH 0/9 v3] xfs: byte-based grant head reservation tracking Dave Chinner
2022-12-20 23:23 ` [PATCH 4/9] xfs: ensure log tail is always up to date Dave Chinner
2023-09-21  1:48 [PATCH 0/9] xfs: byte-based grant head reservation tracking Dave Chinner
2023-09-21  1:48 ` [PATCH 4/9] xfs: ensure log tail is always up to date 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=Ywlb/WABtwa4BocN@magnolia \
    --to=djwong@kernel.org \
    --cc=david@fromorbit.com \
    --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.