[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZXtRBarvgSVN5zPx@casper.infradead.org>
Date: Thu, 14 Dec 2023 19:01:25 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Christoph Hellwig <hch@....de>
Cc: Namjae Jeon <linkinjeon@...nel.org>,
Sungjong Seo <sj1557.seo@...sung.com>, Jan Kara <jack@...e.com>,
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
Mikulas Patocka <mikulas@...ax.karlin.mff.cuni.cz>,
Dave Kleikamp <shaggy@...nel.org>,
Bob Copeland <me@...copeland.com>, linux-fsdevel@...r.kernel.org,
linux-ext4@...r.kernel.org, jfs-discussion@...ts.sourceforge.net,
linux-karma-devel@...ts.sourceforge.net, linux-mm@...ck.org
Subject: Re: [PATCH 4/9] hfs: remove ->writepage
On Sun, Nov 13, 2022 at 05:28:57PM +0100, Christoph Hellwig wrote:
> ->writepage is a very inefficient method to write back data, and only
> used through write_cache_pages or a a fallback when no ->migrate_folio
> method is present.
>
> Set ->migrate_folio to the generic buffer_head based helper, and stop
> wiring up ->writepage for hfs_aops.
>
> Signed-off-by: Christoph Hellwig <hch@....de>
Was there a reason you only did this for hfs_aops and not for
hfs_btree_aops? It feels like anything that just calls
block_write_full_page() in the writepage handler should be converted
to just calling mpage_writepages() in the writepages handler.
I have a few of those conversions done, but obviously they're in
filesystems that are basically untestable.
Powered by blists - more mailing lists