Hi,
On 15/06/18 09:03, Christoph Hellwig wrote:
On Thu, Jun 14, 2018 at 03:04:38PM +0200, Andreas Gruenbacher wrote:
I saw that you've pushed this onto the gfs2-iomap branch in your xfs
repository. I've rebased the gfs2 iomap-write branch onto that;
there's a trivial patch for adding a private pointer to struct iomap
at the head of that branch that would sense to move to the shared
branch as well now.
Please send that patch out ASAP.
The next step would probably be to start using iomap_readpage /
iomap_readpages in gfs2 for block size == page size. This requires
adding inline data support to iomap_readpage which is trivial, but
because of gfs2's reliance on buffer heads, that alone isn't enough.
Is it? At least for block size == page size we will only call
readpage on a pristine, newly allocated page. So buffer heads won't
be in the game at that point, and the iomap buffered write code will
just allocate them for you once we start a write operation, or take
a page fault that makes the page writable.
Yes, for block size == page size, it should not be an issue to drop the
use of buffer heads on reads in GFS2. I was fairly sure that we already
did that in ->readpages() anyway, but it is a while since I looked at
the code and my memory may be playing tricks on me,
Steve.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html