From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: make tr_growdata a permanent transaction
Date: Wed, 17 Apr 2019 07:34:07 -0700 [thread overview]
Message-ID: <20190417143407.GF114154@magnolia> (raw)
In-Reply-To: <20190417095429.GA16377@bfoster>
On Wed, Apr 17, 2019 at 05:54:32AM -0400, Brian Foster wrote:
> On Wed, Apr 17, 2019 at 05:36:08AM -0400, Brian Foster wrote:
> > The growdata transaction is used by growfs operations to increase
> > the data size of the filesystem. Part of this sequence involves
> > extending the size of the last preexisting AG in the fs, if
> > necessary. This is implemented by freeing the newly available
> > physical range to the AG.
> >
> > tr_growdata is not a permanent transaction, however, and block
> > allocation transactions must be permanent to handle deferred frees
> > of AGFL blocks. If the grow operation extends an existing AG that
> > requires AGFL fixing, assert failures occur due to a populated dfops
> > list on a non-permanent transaction and the AGFL free does not
> > occur. This is reproduced (rarely) by xfs/104.
> >
> > Change tr_growdata to a permanent transaction with a default log
> > count. This increases initial transaction reservation size, but
> > growfs is an infrequent and non-performance critical operation and
> > so should have minimal impact. Also add an assert in the block
> > allocation path to make this transaction requirement explicit and
> > obvious to future callers.
> >
> > Reported-by: Darrick J. Wong <darrick.wong@oracle.com>
> > Signed-off-by: Brian Foster <bfoster@redhat.com>
> > ---
> >
> > This is motivated by Darrick's recent xfs/104 failure report[1]. Note
> > that I made the assert a bit more explicit than originally suggested
> > because I think any transaction that performs block allocation should be
> > expected to be able to handle arbitrary AGFL fixups. This survives an
> > fstests auto run without any regressions[2] or assert failures.
> >
> > Brian
> >
> > [1] https://marc.info/?l=linux-xfs&m=155537961822223&w=2
> > [2] Note that I was never able to reproduce the original xfs/104
> > failure.
> >
> > fs/xfs/libxfs/xfs_alloc.c | 2 ++
> > fs/xfs/libxfs/xfs_trans_resv.c | 6 +++++-
> > 2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c
> > index bc3367b8b7bb..e4df1866f949 100644
> > --- a/fs/xfs/libxfs/xfs_alloc.c
> > +++ b/fs/xfs/libxfs/xfs_alloc.c
> > @@ -2237,6 +2237,8 @@ xfs_alloc_fix_freelist(
> > xfs_extlen_t need; /* total blocks needed in freelist */
> > int error = 0;
> >
> > + ASSERT(tp->t_flags & XFS_TRANS_PERM_LOG_RES);
> > +
>
> Naturally, just after sending this I'm reminded I never went back to
> actually audit usage of XFS_ALLOC_FLAG_NOSHRINK. :P NOSHRINK is
> currently used in userspace (repair) and scrub. The former is in a place
> that looks to me like it already uses a permanent transaction. The
> latter is not immediately clear to me. It looks like scrub can alloc
> either tr_itruncate, which is permanent, or an empty transaction. The
> noshrink call is associated with repair, which I think means we'd have
> the permanent transaction (?), but it still might make sense to exclude
> NOSHRINK callers from failing the assert in principle. Thoughts?
Scrub should never be calling xfs_alloc_fix_freelist since it's a
readonly operation, and repair should never be running with an empty
transaction, so this should be fine kernel-side.
As for xfs_repair... yes, it does call libxfs_trans_alloc_rollable to
get a "permanent" transaction (which is actually tr_itruncate too). So
this should be fine in xfsprogs too.
--D
> Brian
>
> > if (!pag->pagf_init) {
> > error = xfs_alloc_read_agf(mp, tp, args->agno, flags, &agbp);
> > if (error)
> > diff --git a/fs/xfs/libxfs/xfs_trans_resv.c b/fs/xfs/libxfs/xfs_trans_resv.c
> > index f99a7aefe418..83f4ee2afc49 100644
> > --- a/fs/xfs/libxfs/xfs_trans_resv.c
> > +++ b/fs/xfs/libxfs/xfs_trans_resv.c
> > @@ -876,9 +876,13 @@ xfs_trans_resv_calc(
> > resp->tr_sb.tr_logres = xfs_calc_sb_reservation(mp);
> > resp->tr_sb.tr_logcount = XFS_DEFAULT_LOG_COUNT;
> >
> > + /* growdata requires permanent res; it can free space to the last AG */
> > + resp->tr_growdata.tr_logres = xfs_calc_growdata_reservation(mp);
> > + resp->tr_growdata.tr_logcount = XFS_DEFAULT_PERM_LOG_COUNT;
> > + resp->tr_growdata.tr_logflags |= XFS_TRANS_PERM_LOG_RES;
> > +
> > /* The following transaction are logged in logical format */
> > resp->tr_ichange.tr_logres = xfs_calc_ichange_reservation(mp);
> > - resp->tr_growdata.tr_logres = xfs_calc_growdata_reservation(mp);
> > resp->tr_fsyncts.tr_logres = xfs_calc_swrite_reservation(mp);
> > resp->tr_writeid.tr_logres = xfs_calc_writeid_reservation(mp);
> > resp->tr_attrsetrt.tr_logres = xfs_calc_attrsetrt_reservation(mp);
> > --
> > 2.17.2
> >
next prev parent reply other threads:[~2019-04-17 14:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-17 9:36 [PATCH] xfs: make tr_growdata a permanent transaction Brian Foster
2019-04-17 9:54 ` Brian Foster
2019-04-17 14:34 ` Darrick J. Wong [this message]
2019-04-17 14:37 ` Darrick J. Wong
2019-04-17 15:33 ` Brian Foster
2019-04-17 15:47 ` Darrick J. Wong
2019-04-23 6:24 ` Christoph Hellwig
2019-04-23 15:04 ` Darrick J. Wong
-- strict thread matches above, loose matches on Subject: below --
2019-04-23 15:07 Darrick J. Wong
2019-04-23 15:28 ` Brian Foster
2019-04-23 15:49 ` Darrick J. Wong
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=20190417143407.GF114154@magnolia \
--to=darrick.wong@oracle.com \
--cc=bfoster@redhat.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.