[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgjMNbNG0FMatHtmzEZPj0ZmQpNRsnRvH47igJoC9TBww@mail.gmail.com>
Date: Sun, 22 Jan 2023 12:05:53 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andreas Gruenbacher <agruenba@...hat.com>,
David Howells <dhowells@...hat.com>,
Steve French <smfrench@...il.com>,
"Theodore Ts'o" <tytso@....edu>, Jan Kara <jack@...e.cz>,
Trond Myklebust <trondmy@...merspace.com>,
Christoph Hellwig <hch@....de>,
"Darrick J. Wong" <djwong@...nel.org>
Cc: cluster-devel@...hat.com, linux-kernel@...r.kernel.org,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [GIT PULL] gfs2 writepage fix
On Sun, Jan 22, 2023 at 1:01 AM Andreas Gruenbacher <agruenba@...hat.com> wrote:
>
> gfs2 writepage fix
>
> - Fix a regression introduced by commit "gfs2: stop using
> generic_writepages in gfs2_ail1_start_one".
Hmm. I'm adding a few more people and linux-fsdevel to the reply,
because we had a number of filesystems remove writepages use lately,
including some that did it as a fix after the merge window.
Everybody involved seemed to claim it was just a no-brainer
switch-over, and I just took that on faith. Now it looks like that
wasn't true at least for gfs2 due to different semantics.
Maybe the gfs2 issue is purely because of how gfs2 did the conversion
(generic_writepages -> filemap_fdatawrite_wbc), but let's make people
look at their own cases.
Linus
Powered by blists - more mailing lists