From: Brian Foster <bfoster@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Christoph Hellwig <hch@infradead.org>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 00/14] xfs: embed dfops in the transaction
Date: Fri, 20 Jul 2018 10:41:07 -0400 [thread overview]
Message-ID: <20180720144106.GB34727@bfoster> (raw)
In-Reply-To: <20180719213634.GN4813@magnolia>
On Thu, Jul 19, 2018 at 02:36:34PM -0700, Darrick J. Wong wrote:
> On Thu, Jul 19, 2018 at 04:36:43PM -0400, Brian Foster wrote:
> > On Thu, Jul 19, 2018 at 01:05:57PM -0700, Christoph Hellwig wrote:
> > > On Thu, Jul 19, 2018 at 09:49:05AM -0400, Brian Foster wrote:
> > > > return a clean transaction. Other things to consider might be to do away
> > > > with support for external dfops and the ->t_dfops pointer indirection,
> > > > or perhaps even consider going the other direction: allocate dfops from
> > > > a separate zone to save some memory on non-permanent transactions (note
> > > > that 16 of 28 transactions use a permanent log res. last I looked, so it
> > > > may not be worth it atm).
> > >
> > > The defer_ops aren't really that big, and allocations are relatively
> > > costly, so I don't think a separate allocation is a good idea. If we
> > > really want to optimize the non-permanent transaction case we could do
> > > something like:
> > >
> > > struct xfs_trans {
> > > ...
> > > struct xfs_defer_ops dfops[];
> > > };
> > >
> > > and then have two caches for the with an without dfops case. But
> > > I can't believe that would be worth it, especially in face of...
> > >
> > >
> > > > I know Christoph also had thoughts around condensing some of the items
> > > > joined to the dfops to those with the transaction.
> > >
> > > ... this.
> > >
> >
> > Yeah. I was actually poking around today after writing this up and
> > thought that we might be able to replace both dop_inodes/dop_bufs with
> > checks in the transaction item list for either held buffers or inode
> > items where lock_flags == 0. I _think_ both of those states may be
> > essentially equivalent to joined dfops items, but I have to verify that.
> > If so, we can probably make the dfops inode/buf relogging "automatic,"
> > drop both pointer lists and the whole memory thing becomes kind of moot.
>
> <nod>
>
Ok.. on this one, running some tests shows that pretty much all dfops
joined bufs/inodes are essentially held in the transaction (which would
probably be a bug if that were not the case). The opposite is also true
for buffers, because a held buffers must also be held in subsequent
transactions to ensure the caller still has a reference after dfops
completion. OTOH, there are some places where inodes are joined to a
transaction with lock_flags == 0 and dfops are run without the inode
joined to the dfops. I don't necessarily think this is a bug for the
inode case because the caller still owns the inode lock, we just don't
relog it across the series of transactions required for dfops
completion.
I don't think it would necessarily be a problem if we did relog the
inode in these cases, however. In fact I think the argument has been
made in the past to do that explicitly (with xfs_defer_[i|b]join()) in
one or two cases. So given that, the overall approach still seems
reasonable enough to me. FWIW, the appended patch shows the cases I've
caught on a quick xfstests run that would be affected (i.e., where we
don't currently defer_ijoin() but implicitly would with an "automatic"
relog mechanism). I'm running a longer test to try and catch any others,
but let me know if anybody sees problems with this or has other ideas...
Brian
--- 8< ---
diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
index 60138514ea86..c3cbe05cdb1b 100644
--- a/fs/xfs/libxfs/xfs_bmap.c
+++ b/fs/xfs/libxfs/xfs_bmap.c
@@ -1120,6 +1120,7 @@ xfs_bmap_add_attrfork(
xfs_log_sb(tp);
}
+ xfs_defer_ijoin(tp->t_dfops, ip);
error = xfs_trans_commit(tp);
xfs_iunlock(ip, XFS_ILOCK_EXCL);
return error;
diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index 7b40e9fef381..e63712e67fd8 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -979,6 +979,7 @@ xfs_alloc_file_space(
/*
* Complete the transaction
*/
+ xfs_defer_ijoin(tp->t_dfops, ip);
error = xfs_trans_commit(tp);
xfs_iunlock(ip, XFS_ILOCK_EXCL);
if (error)
diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
index 0e4bd559a6a7..24fdca90b588 100644
--- a/fs/xfs/xfs_inode.c
+++ b/fs/xfs/xfs_inode.c
@@ -1810,6 +1810,7 @@ xfs_inactive_ifree(
* Just ignore errors at this point. There is nothing we can do except
* to try to keep going. Make sure it's not a silent error.
*/
+ xfs_defer_ijoin(tp->t_dfops, ip);
error = xfs_trans_commit(tp);
if (error)
xfs_notice(mp, "%s: xfs_trans_commit returned error %d",
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 8e8ca9f03f0e..464b4b3225bb 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -261,6 +261,7 @@ xfs_iomap_write_direct(
/*
* Complete the transaction
*/
+ xfs_defer_ijoin(tp->t_dfops, ip);
error = xfs_trans_commit(tp);
if (error)
goto out_unlock;
@@ -762,6 +763,7 @@ xfs_iomap_write_allocate(
if (error)
goto trans_cancel;
+ xfs_defer_ijoin(tp->t_dfops, ip);
error = xfs_trans_commit(tp);
if (error)
goto error0;
@@ -879,6 +881,7 @@ xfs_iomap_write_unwritten(
xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE);
}
+ xfs_defer_ijoin(tp->t_dfops, ip);
error = xfs_trans_commit(tp);
xfs_iunlock(ip, XFS_ILOCK_EXCL);
if (error)
diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
index cddde219630a..8984f283da7b 100644
--- a/fs/xfs/xfs_reflink.c
+++ b/fs/xfs/xfs_reflink.c
@@ -435,6 +435,7 @@ xfs_reflink_allocate_cow(
xfs_inode_set_cowblocks_tag(ip);
/* Finish up. */
+ xfs_defer_ijoin(tp->t_dfops, ip);
error = xfs_trans_commit(tp);
if (error)
return error;
next prev parent reply other threads:[~2018-07-20 15:29 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-19 13:49 [PATCH 00/14] xfs: embed dfops in the transaction Brian Foster
2018-07-19 13:49 ` [PATCH 01/14] xfs: pull up dfops from xfs_itruncate_extents() Brian Foster
2018-07-19 19:50 ` Christoph Hellwig
2018-07-19 13:49 ` [PATCH 02/14] xfs: use ->t_dfops in log recovery intent processing Brian Foster
2018-07-19 19:50 ` Christoph Hellwig
2018-07-19 13:49 ` [PATCH 03/14] xfs: fix transaction leak on remote attr set/remove failure Brian Foster
2018-07-19 19:51 ` Christoph Hellwig
2018-07-19 13:49 ` [PATCH 04/14] xfs: make deferred processing safe for embedded dfops Brian Foster
2018-07-19 19:52 ` Christoph Hellwig
2018-07-19 13:49 ` [PATCH 05/14] xfs: remove unused deferred ops committed field Brian Foster
2018-07-19 19:53 ` Christoph Hellwig
2018-07-19 13:49 ` [PATCH 06/14] xfs: reset dfops to initial state after finish Brian Foster
2018-07-19 19:54 ` Christoph Hellwig
2018-07-19 20:33 ` Brian Foster
2018-07-20 16:07 ` Christoph Hellwig
2018-07-19 13:49 ` [PATCH 07/14] xfs: pack holes in xfs_defer_ops and xfs_trans Brian Foster
2018-07-19 19:54 ` Christoph Hellwig
2018-07-19 13:49 ` [PATCH 08/14] xfs: support embedded dfops in transaction Brian Foster
2018-07-19 16:18 ` Brian Foster
2018-07-19 19:47 ` Christoph Hellwig
2018-07-19 20:31 ` Brian Foster
2018-07-20 16:05 ` Christoph Hellwig
2018-07-20 16:27 ` Darrick J. Wong
2018-07-19 19:56 ` Christoph Hellwig
2018-07-19 20:32 ` Brian Foster
2018-07-20 16:06 ` Christoph Hellwig
2018-07-19 13:49 ` [PATCH 09/14] xfs: use internal dfops in cow blocks cancel Brian Foster
2018-07-19 19:57 ` Christoph Hellwig
2018-07-19 20:33 ` Brian Foster
2018-07-19 13:49 ` [PATCH 10/14] xfs: use internal dfops in attr code Brian Foster
2018-07-19 13:49 ` [PATCH 11/14] xfs: use internal dfops during [b|c]ui recovery Brian Foster
2018-07-19 13:49 ` [PATCH 12/14] xfs: remove all boilerplate defer init/finish code Brian Foster
2018-07-19 13:49 ` [PATCH 13/14] xfs: remove unnecessary dfops init calls in xattr code Brian Foster
2018-07-19 13:49 ` [PATCH 14/14] xfs: drop unnecessary xfs_defer_finish() dfops parameter Brian Foster
2018-07-19 20:05 ` [PATCH 00/14] xfs: embed dfops in the transaction Christoph Hellwig
2018-07-19 20:36 ` Brian Foster
2018-07-19 21:36 ` Darrick J. Wong
2018-07-20 14:06 ` Brian Foster
2018-07-20 14:41 ` Brian Foster [this message]
2018-07-20 16:11 ` Christoph Hellwig
2018-07-20 16:09 ` Christoph Hellwig
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=20180720144106.GB34727@bfoster \
--to=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=hch@infradead.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 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).