[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191008064235.GB30465@lst.de>
Date: Tue, 8 Oct 2019 08:42:35 +0200
From: Christoph Hellwig <hch@....de>
To: Dave Chinner <david@...morbit.com>
Cc: Christoph Hellwig <hch@....de>,
"Darrick J . Wong" <darrick.wong@...cle.com>,
Damien Le Moal <Damien.LeMoal@....com>,
Andreas Gruenbacher <agruenba@...hat.com>,
linux-xfs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org,
Carlos Maiolino <cmaiolino@...hat.com>
Subject: Re: [PATCH 08/11] xfs: use a struct iomap in xfs_writepage_ctx
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.
Powered by blists - more mailing lists