From: Brian Foster <bfoster@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 7/7] xfs: rework secondary superblock updates in growfs
Date: Fri, 9 Feb 2018 11:12:41 -0500 [thread overview]
Message-ID: <20180209161240.GD21413@bfoster.bfoster> (raw)
In-Reply-To: <20180201064202.7174-8-david@fromorbit.com>
On Thu, Feb 01, 2018 at 05:42:02PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> Right now we wait until we've committed changes to the primary
> superblock before we initialise any of the new secondary
> superblocks. This means that if we have any write errors for new
> secondary superblocks we end up with garbage in place rather than
> zeros or even an "in progress" superblock to indicate a grow
> operation is being done.
>
> To ensure we can write the secondary superblocks, initialise them
> earlier in the same loop that initialises the AG headers. We stamp
> the new secondary superblocks here with the old geometry, but set
> the "sb_inprogress" field to indicate that updates are being done to
> the superblock so they cannot be used. This will result in the
> secondary superblock fields being updated or triggering errors that
> will abort the grow before we commit any permanent changes.
>
> This also means we can change the update mechanism of the secondary
> superblocks. We know that we are going to wholly overwrite the
> information in the struct xfs_sb in the buffer, so there's no point
> reading it from disk. Just allocate an uncached buffer, zero it in
> memory, stamp the new superblock structure in it and write it out.
> If we fail to write it out, then we'll leave the existing sb (old or
> new w/ inprogress) on disk for repair to deal with later.
>
> Signed-Off-By: Dave Chinner <dchinner@redhat.com>
> ---
> fs/xfs/xfs_fsops.c | 92 ++++++++++++++++++++++++++++++++----------------------
> 1 file changed, 55 insertions(+), 37 deletions(-)
>
> diff --git a/fs/xfs/xfs_fsops.c b/fs/xfs/xfs_fsops.c
> index 113be7dbdc81..7318cebb591d 100644
> --- a/fs/xfs/xfs_fsops.c
> +++ b/fs/xfs/xfs_fsops.c
...
> @@ -630,43 +653,27 @@ xfs_growfs_imaxpct(
>
...
> static int
> xfs_growfs_update_superblocks(
...
> /* update secondary superblocks. */
> for (agno = 1; agno < mp->m_sb.sb_agcount; agno++) {
> - error = 0;
> - /*
> - * new secondary superblocks need to be zeroed, not read from
> - * disk as the contents of the new area we are growing into is
> - * completely unknown.
> - */
> - if (agno < oagcount) {
> - error = xfs_trans_read_buf(mp, NULL, mp->m_ddev_targp,
> - XFS_AGB_TO_DADDR(mp, agno, XFS_SB_BLOCK(mp)),
> - XFS_FSS_TO_BB(mp, 1), 0, &bp,
> - &xfs_sb_buf_ops);
> - } else {
> - bp = xfs_trans_get_buf(NULL, mp->m_ddev_targp,
> - XFS_AGB_TO_DADDR(mp, agno, XFS_SB_BLOCK(mp)),
> - XFS_FSS_TO_BB(mp, 1), 0);
> - if (bp) {
> - bp->b_ops = &xfs_sb_buf_ops;
> - xfs_buf_zero(bp, 0, BBTOB(bp->b_length));
> - } else
> - error = -ENOMEM;
> - }
> + struct xfs_buf *bp;
>
> + bp = xfs_growfs_get_hdr_buf(mp,
> + XFS_AG_DADDR(mp, agno, XFS_SB_DADDR),
> + XFS_FSS_TO_BB(mp, 1), 0, &xfs_sb_buf_ops);
This all seems fine to me up until the point where we use uncached
buffers for pre-existing secondary superblocks. This may all be fine now
if nothing else happens to access/use secondary supers, but it seems
like this essentially enforces that going forward.
Hmm, I see that scrub does appear to look at secondary superblocks via
cached buffers. Shouldn't we expect this path to maintain coherency with
an sb buffer that may have been read/cached from there?
Brian
> /*
> * If we get an error reading or writing alternate superblocks,
> * continue. xfs_repair chooses the "best" superblock based
> @@ -674,25 +681,38 @@ xfs_growfs_update_superblocks(
> * superblocks un-updated than updated, and xfs_repair may
> * pick them over the properly-updated primary.
> */
> - if (error) {
> + if (!bp) {
> xfs_warn(mp,
> - "error %d reading secondary superblock for ag %d",
> - error, agno);
> - saved_error = error;
> + "error allocating secondary superblock for ag %d",
> + agno);
> + if (!saved_error)
> + saved_error = -ENOMEM;
> continue;
> }
> xfs_sb_to_disk(XFS_BUF_TO_SBP(bp), &mp->m_sb);
> -
> - error = xfs_bwrite(bp);
> + xfs_buf_delwri_queue(bp, &buffer_list);
> xfs_buf_relse(bp);
> +
> + /* don't hold too many buffers at once */
> + if (agno % 16)
> + continue;
> +
> + error = xfs_buf_delwri_submit(&buffer_list);
> if (error) {
> xfs_warn(mp,
> - "write error %d updating secondary superblock for ag %d",
> + "write error %d updating a secondary superblock near ag %d",
> error, agno);
> - saved_error = error;
> + if (!saved_error)
> + saved_error = error;
> continue;
> }
> }
> + error = xfs_buf_delwri_submit(&buffer_list);
> + if (error) {
> + xfs_warn(mp,
> + "write error %d updating a secondary superblock near ag %d",
> + error, agno);
> + }
>
> return saved_error ? saved_error : error;
> }
> @@ -707,7 +727,6 @@ xfs_growfs_data(
> struct xfs_mount *mp,
> struct xfs_growfs_data *in)
> {
> - xfs_agnumber_t oagcount;
> int error = 0;
>
> if (!capable(CAP_SYS_ADMIN))
> @@ -722,7 +741,6 @@ xfs_growfs_data(
> goto out_error;
> }
>
> - oagcount = mp->m_sb.sb_agcount;
> error = xfs_growfs_data_private(mp, in);
> if (error)
> goto out_error;
> @@ -740,7 +758,7 @@ xfs_growfs_data(
> /*
> * Update secondary superblocks now the physical grow has completed
> */
> - error = xfs_growfs_update_superblocks(mp, oagcount);
> + error = xfs_growfs_update_superblocks(mp);
>
> out_error:
> /*
> --
> 2.15.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-02-09 16:12 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 6:41 [PATCH 0/7] xfs: refactor and tablise growfs Dave Chinner
2018-02-01 6:41 ` [PATCH 1/7] xfs: factor out AG header initialisation from growfs core Dave Chinner
2018-02-08 18:53 ` Brian Foster
2018-02-01 6:41 ` [PATCH 2/7] xfs: convert growfs AG header init to use buffer lists Dave Chinner
2018-02-08 18:53 ` Brian Foster
2018-02-01 6:41 ` [PATCH 3/7] xfs: factor ag btree reoot block initialisation Dave Chinner
2018-02-08 18:54 ` Brian Foster
2018-02-08 20:00 ` Darrick J. Wong
2018-02-09 13:10 ` Brian Foster
2018-02-12 0:45 ` Darrick J. Wong
2018-02-15 5:53 ` Darrick J. Wong
2018-02-01 6:41 ` [PATCH 4/7] xfs: turn ag header initialisation into a table driven operation Dave Chinner
2018-02-09 16:11 ` Brian Foster
2018-02-01 6:42 ` [PATCH 5/7] xfs: make imaxpct changes in growfs separate Dave Chinner
2018-02-09 16:11 ` Brian Foster
2018-02-15 22:10 ` Dave Chinner
2018-02-01 6:42 ` [PATCH 6/7] xfs: separate secondary sb update in growfs Dave Chinner
2018-02-09 16:11 ` Brian Foster
2018-02-15 22:23 ` Dave Chinner
2018-02-16 12:31 ` Brian Foster
2018-02-01 6:42 ` [PATCH 7/7] xfs: rework secondary superblock updates " Dave Chinner
2018-02-09 16:12 ` Brian Foster [this message]
2018-02-15 22:31 ` Dave Chinner
2018-02-16 12:56 ` Brian Foster
2018-02-16 16:20 ` Darrick J. Wong
2018-02-19 2:16 ` Dave Chinner
2018-02-19 13:21 ` Brian Foster
2018-02-19 22:14 ` Dave Chinner
2018-02-20 12:44 ` Brian Foster
2018-03-24 0:37 ` Darrick J. Wong
2018-02-06 23:44 ` [PATCH 0/7] xfs: refactor and tablise growfs Darrick J. Wong
2018-02-07 7:10 ` 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=20180209161240.GD21413@bfoster.bfoster \
--to=bfoster@redhat.com \
--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 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).