public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: Assertions tripping in xfs/104
Date: Tue, 16 Apr 2019 08:00:59 -0400	[thread overview]
Message-ID: <20190416120056.GA14042@bfoster> (raw)
In-Reply-To: <20190416015328.GL4752@magnolia>

On Mon, Apr 15, 2019 at 06:53:28PM -0700, Darrick J. Wong wrote:
> Hi Brian,
> 
> When running fstests against what will become the xfs-5.2-merge tree, I
> hit an assert in xfs/104; the dmesg for that is pasted below.
> 
> I'm pretty sure that what's going on here is that we hit a deferred AGFL
> free while growing the filesystem and need to do a defer_roll, but
> tr_growdata is not one of the permanent reservation transactions and
> that's why we trip some asserts.
> 

Yeah, it looks like we can hit this in the case where a growfs extends
the last pre-existing AG in the fs. We "free" the additional space into
the AG, happen to come across an overpopulated AGFL and end up doing
deferred ops from a non-permanent transaction.

I think we should probably just update the tr_growdata transaction to
reflect how it's used and mark it permanent with the default permanent
log count (2). That obviously increases the reservation size, but it's
not like grow is a high frequency or performance critical operation.

> FSTYP         -- xfs (debug)
> PLATFORM      -- Linux/x86_64 mtr01 5.1.0-rc5-djw
> MKFS_OPTIONS  -- -f -m reflink=1,rmapbt=1, -i sparse=1, -b size=1024, /dev/sdd
> MOUNT_OPTIONS -- -o usrquota,grpquota,prjquota, /dev/sdd /opt
> 
> Granted this is the first time I've seen this in several months of
> nightly fstests runs, so chances are this one is hard to reproduce.
> 

I don't recall seeing this and don't reproduce in a few iterations of
xfs/104 with the above geometry. I'll keep trying for a bit. In the
meantime, a diff is appended if you'd like to give that a try. Thoughts?

Brian

--- 8< ---

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);

  reply	other threads:[~2019-04-16 12:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-16  1:53 Assertions tripping in xfs/104 Darrick J. Wong
2019-04-16 12:00 ` Brian Foster [this message]
2019-04-16 15:26   ` Darrick J. Wong
2019-04-16 18:23     ` Brian Foster
2019-04-16 18:59       ` Darrick J. Wong
2019-04-16 21:21         ` 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=20190416120056.GA14042@bfoster \
    --to=bfoster@redhat.com \
    --cc=darrick.wong@oracle.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