From: Christoph Hellwig <hch@infradead.org>
To: Brian Foster <bfoster@redhat.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
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 09:11:37 -0700 [thread overview]
Message-ID: <20180720161137.GG12054@infradead.org> (raw)
In-Reply-To: <20180720144106.GB34727@bfoster>
On Fri, Jul 20, 2018 at 10:41:07AM -0400, Brian Foster wrote:
> 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).
That's what I'd expect.
> 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 suspect many of those are a bug. Yes, we could have deferred ops
that don't need the inode, but in general we'd want the same objects
for the deferred inode.
That being said we could always have an indicator for that case, but
I'd rather make it opt-in than opt-out.
next prev parent reply other threads:[~2018-07-20 17:00 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
2018-07-20 16:11 ` Christoph Hellwig [this message]
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=20180720161137.GG12054@infradead.org \
--to=hch@infradead.org \
--cc=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;
as well as URLs for NNTP newsgroup(s).