lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 15 Jun 2018 09:31:26 +0100 From: Steven Whitehouse <swhiteho@...hat.com> To: Christoph Hellwig <hch@....de>, Andreas Gruenbacher <agruenba@...hat.com> Cc: cluster-devel <cluster-devel@...hat.com>, linux-xfs@...r.kernel.org, linux-fsdevel <linux-fsdevel@...r.kernel.org>, Dan Williams <dan.j.williams@...el.com>, linux-ext4 <linux-ext4@...r.kernel.org> Subject: Re: [Cluster-devel] iomap preparations for GFS2 v2 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.
Powered by blists - more mailing lists