linux-kernel - Re: lift the xfs writepage code into iomap v2

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190628054251.GC26902@lst.de>
Date:   Fri, 28 Jun 2019 07:42:51 +0200
From:   Christoph Hellwig <hch@....de>
To:     "Darrick J. Wong" <darrick.wong@...cle.com>
Cc:     Christoph Hellwig <hch@....de>,
        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
Subject: Re: lift the xfs writepage code into iomap v2

On Thu, Jun 27, 2019 at 06:32:56PM -0700, Darrick J. Wong wrote:
> I think Dave has voiced some valid concerns about our ability to support
> this code over the long term once we start sharing it with other fses.
> XFS has a longish history of sailing away from generic code so that we
> can remove awkward abstractions which aren't working well for us.  If
> we're going to continue to go our own way with things like file locking
> and mapping I wonder how long we'd keep using the iomap ioends before
> moving away again.  How well will that iomap code avoid bitrot once XFS
> does that?

As outlied in my mail to Dave I agree with the high level issue.
But I very much thing that the writeback code is and should be generic.
For one it is much more tightly integrated with other iomap code
than with XFS.  And second the kernel doesn't have a sane generic
writeback implementation.  We have like three different crappy buffer
head ones, and anyone wanting to sanely implement writeback currently
has to write their own, which is a major PITA.

> How does that sound?  Who are the other potential users?

The immediate current user is Damiens zonefs, which is just a thin
abstraction on top of zones in zoned block devices.  Then my plan has
always been to convert gfs2 over to it, away from buffer heads.  With
btrfs now joining iomap land I'd be really excited to move it over,
but we'll see how feasily that is.  But with gfs2 done I think we
also are ready to convert anything currently using plain old buffer
heads over, so things like sysvfs, minix, jfs, etc.  While that isn't
a priority and will take a while it will help with my grand overall
scheme of killing buffer_heads, at least for the data path.