linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@lst.de>,
	"Darrick J . Wong" <darrick.wong@oracle.com>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	Andreas Gruenbacher <agruenba@redhat.com>,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Carlos Maiolino <cmaiolino@redhat.com>
Subject: Re: [PATCH 08/11] xfs: use a struct iomap in xfs_writepage_ctx
Date: Tue, 8 Oct 2019 08:42:35 +0200	[thread overview]
Message-ID: <20191008064235.GB30465@lst.de> (raw)
In-Reply-To: <20191007215423.GB16973@dread.disaster.area>

On Tue, Oct 08, 2019 at 08:54:24AM +1100, Dave Chinner wrote:
> > +	if (whichfork == XFS_COW_FORK)
> > +		flags |= IOMAP_F_SHARED;
> 
> That seems out of place - I don't see anywhere in this patch that
> moves/removes setting the IOMAP_F_SHARED flag. i.e this looks like a
> change of behaviour....

It is a change of representation, not behavior.  Before this patch we
used a struct xfs_bmbt_irec + int fork in xfs_writepage_ctx to hold the
current writeback extent.  We now use a iomap, which wants this flag to
have the fork information.  The fork flag is removed later when switching
to the iomap implementation to avoid extra churn.

Before Darricks reshuffling there was an extra patch making this
transition more clear:

	http://git.infradead.org/users/hch/xfs.git/commitdiff/5274577088ffcfcfbf735dcfe4153d699027caad

but since the series was turned upside down and creates the iomap code
out of the thin air all these easy to understand and verify step by
step changes to the existing xfs codebase got lost unfortunately.

  reply	other threads:[~2019-10-08  6:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-06 15:45 lift the xfs writepage code into iomap v6 Christoph Hellwig
2019-10-06 15:45 ` [PATCH 01/11] iomap: add tracing for the readpage / readpages Christoph Hellwig
2019-10-06 22:43   ` Darrick J. Wong
2019-10-07  5:48     ` Christoph Hellwig
2019-10-07  6:17       ` Christoph Hellwig
2019-10-07 15:23         ` Darrick J. Wong
2019-10-07 13:00   ` Brian Foster
2019-10-06 15:45 ` [PATCH 02/11] iomap: copy the xfs writeback code to iomap.c Christoph Hellwig
2019-10-07 21:43   ` Dave Chinner
2019-10-08  6:34     ` Christoph Hellwig
2019-10-08  7:37       ` Dave Chinner
2019-10-06 15:46 ` [PATCH 03/11] iomap: warn on inline maps in iomap_writepage_map Christoph Hellwig
2019-10-06 15:46 ` [PATCH 04/11] xfs: set IOMAP_F_NEW more carefully Christoph Hellwig
2019-10-06 15:46 ` [PATCH 05/11] iomap: zero newly allocated mapped blocks Christoph Hellwig
2019-10-07 21:46   ` Dave Chinner
2019-10-07 22:08     ` Dave Chinner
2019-10-06 15:46 ` [PATCH 06/11] xfs: remove the readpage / readpages tracing code Christoph Hellwig
2019-10-06 15:46 ` [PATCH 07/11] xfs: initialize iomap->flags in xfs_bmbt_to_iomap Christoph Hellwig
2019-10-06 15:46 ` [PATCH 08/11] xfs: use a struct iomap in xfs_writepage_ctx Christoph Hellwig
2019-10-07 21:54   ` Dave Chinner
2019-10-08  6:42     ` Christoph Hellwig [this message]
2019-10-06 15:46 ` [PATCH 09/11] xfs: remove the fork fields in the writepage_ctx and ioend Christoph Hellwig
2019-10-07 21:59   ` Dave Chinner
2019-10-08  6:12     ` Christoph Hellwig
2019-10-06 15:46 ` [PATCH 10/11] xfs: use the iomap writeback code Christoph Hellwig
2019-10-07 13:06   ` Brian Foster
2019-10-07 15:25   ` Darrick J. Wong
2019-10-06 15:46 ` [PATCH 11/11] iomap: move struct iomap_page out of iomap.h Christoph Hellwig
  -- strict thread matches above, loose matches on Subject: below --
2019-10-01  7:11 lift the xfs writepage code into iomap v5 Christoph Hellwig
2019-10-01  7:11 ` [PATCH 08/11] xfs: use a struct iomap in xfs_writepage_ctx 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=20191008064235.GB30465@lst.de \
    --to=hch@lst.de \
    --cc=Damien.LeMoal@wdc.com \
    --cc=agruenba@redhat.com \
    --cc=cmaiolino@redhat.com \
    --cc=darrick.wong@oracle.com \
    --cc=david@fromorbit.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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).