From: Jan Kara <jack@suse.cz>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jan Kara <jack@suse.cz>, Christoph Hellwig <hch@lst.de>,
Namjae Jeon <linkinjeon@kernel.org>,
Sungjong Seo <sj1557.seo@samsung.com>, Jan Kara <jack@suse.com>,
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>,
Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>,
Dave Kleikamp <shaggy@kernel.org>,
Bob Copeland <me@bobcopeland.com>,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
jfs-discussion@lists.sourceforge.net,
linux-karma-devel@lists.sourceforge.net, linux-mm@kvack.org
Subject: Re: [PATCH 2/9] ext2: remove ->writepageo
Date: Wed, 16 Nov 2022 19:20:40 +0100 [thread overview]
Message-ID: <20221116182040.tecis3dqejsdqnum@quack3> (raw)
In-Reply-To: <Y3UMV2mB5BkMM5PY@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1324 bytes --]
On Wed 16-11-22 08:14:15, Christoph Hellwig wrote:
> On Mon, Nov 14, 2022 at 11:49:27AM +0100, Jan Kara wrote:
> > On Sun 13-11-22 17:28:55, 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.
> > >
> > > Signed-off-by: Christoph Hellwig <hch@lst.de>
> >
> > Looks good! Feel free to add:
>
> The testbot found a problem with this:
>
> ext2_commit_chunk calls write_one_page for the IS_DIRSYNC case,
> and write_one_page calls ->writepage.
Right.
> So I think I need to drop this one for now (none of the other
> file systems calls write_one_page). And then think what best
> to do about write_one_page/write_one_folio. I suspect just
> passing a writepage pointer to them might make most sense,
> as they are only used by a few file systems, and the calling
> convention with the locked page doesn't lend itself to using
> ->writepages.
Looking at the code, IMO the write_one_page() looks somewhat premature
anyway in that place. AFAICS we could handle the writeout using
filemap_write_and_wait() if we moved it to somewhat later moment. So
something like attached patch (only basic testing only so far)?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
[-- Attachment #2: 0001-ext2-Don-t-flush-page-immediately-for-DIRSYNC-direct.patch --]
[-- Type: text/x-patch, Size: 3880 bytes --]
From dc36b90da4c23134ac2fd02d7a21a736fe68d598 Mon Sep 17 00:00:00 2001
From: Jan Kara <jack@suse.cz>
Date: Wed, 16 Nov 2022 19:08:23 +0100
Subject: [PATCH] ext2: Don't flush page immediately for DIRSYNC directories
We do not need to writeout modified directory blocks immediately when
modifying them while the page is locked. It is enough to do the flush
somewhat later which has the added benefit that inode times can be
flushed as well. It also allows us to stop depending on
write_one_page() function.
Signed-off-by: Jan Kara <jack@suse.cz>
---
fs/ext2/dir.c | 37 +++++++++++++++++++++----------------
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
index 8f597753ac12..17efc784af53 100644
--- a/fs/ext2/dir.c
+++ b/fs/ext2/dir.c
@@ -81,11 +81,10 @@ ext2_last_byte(struct inode *inode, unsigned long page_nr)
return last_byte;
}
-static int ext2_commit_chunk(struct page *page, loff_t pos, unsigned len)
+static void ext2_commit_chunk(struct page *page, loff_t pos, unsigned len)
{
struct address_space *mapping = page->mapping;
struct inode *dir = mapping->host;
- int err = 0;
inode_inc_iversion(dir);
block_write_end(NULL, mapping, pos, len, len, page, NULL);
@@ -94,16 +93,7 @@ static int ext2_commit_chunk(struct page *page, loff_t pos, unsigned len)
i_size_write(dir, pos+len);
mark_inode_dirty(dir);
}
-
- if (IS_DIRSYNC(dir)) {
- err = write_one_page(page);
- if (!err)
- err = sync_inode_metadata(dir, 1);
- } else {
- unlock_page(page);
- }
-
- return err;
+ unlock_page(page);
}
static bool ext2_check_page(struct page *page, int quiet, char *kaddr)
@@ -460,6 +450,17 @@ static int ext2_prepare_chunk(struct page *page, loff_t pos, unsigned len)
return __block_write_begin(page, pos, len, ext2_get_block);
}
+
+static int ext2_handle_dirsync(struct inode *dir)
+{
+ int err;
+
+ err = filemap_write_and_wait(dir->i_mapping);
+ if (!err)
+ err = sync_inode_metadata(dir, 1);
+ return err;
+}
+
void ext2_set_link(struct inode *dir, struct ext2_dir_entry_2 *de,
struct page *page, void *page_addr, struct inode *inode,
int update_times)
@@ -474,11 +475,12 @@ void ext2_set_link(struct inode *dir, struct ext2_dir_entry_2 *de,
BUG_ON(err);
de->inode = cpu_to_le32(inode->i_ino);
ext2_set_de_type(de, inode);
- err = ext2_commit_chunk(page, pos, len);
+ ext2_commit_chunk(page, pos, len);
if (update_times)
dir->i_mtime = dir->i_ctime = current_time(dir);
EXT2_I(dir)->i_flags &= ~EXT2_BTREE_FL;
mark_inode_dirty(dir);
+ ext2_handle_dirsync(dir);
}
/*
@@ -566,10 +568,11 @@ int ext2_add_link (struct dentry *dentry, struct inode *inode)
memcpy(de->name, name, namelen);
de->inode = cpu_to_le32(inode->i_ino);
ext2_set_de_type (de, inode);
- err = ext2_commit_chunk(page, pos, rec_len);
+ ext2_commit_chunk(page, pos, rec_len);
dir->i_mtime = dir->i_ctime = current_time(dir);
EXT2_I(dir)->i_flags &= ~EXT2_BTREE_FL;
mark_inode_dirty(dir);
+ err = ext2_handle_dirsync(dir);
/* OFFSET_CACHE */
out_put:
ext2_put_page(page, page_addr);
@@ -615,10 +618,11 @@ int ext2_delete_entry (struct ext2_dir_entry_2 *dir, struct page *page,
if (pde)
pde->rec_len = ext2_rec_len_to_disk(to - from);
dir->inode = 0;
- err = ext2_commit_chunk(page, pos, to - from);
+ ext2_commit_chunk(page, pos, to - from);
inode->i_ctime = inode->i_mtime = current_time(inode);
EXT2_I(inode)->i_flags &= ~EXT2_BTREE_FL;
mark_inode_dirty(inode);
+ err = ext2_handle_dirsync(dir);
out:
return err;
}
@@ -658,7 +662,8 @@ int ext2_make_empty(struct inode *inode, struct inode *parent)
memcpy (de->name, "..\0", 4);
ext2_set_de_type (de, inode);
kunmap_atomic(kaddr);
- err = ext2_commit_chunk(page, 0, chunk_size);
+ ext2_commit_chunk(page, 0, chunk_size);
+ err = ext2_handle_dirsync(inode);
fail:
put_page(page);
return err;
--
2.35.3
next prev parent reply other threads:[~2022-11-16 18:20 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-13 16:28 start removing writepage instances Christoph Hellwig
2022-11-13 16:28 ` [PATCH 1/9] extfat: remove ->writepage Christoph Hellwig
2022-11-14 11:07 ` Namjae Jeon
2022-11-13 16:28 ` [PATCH 2/9] ext2: " Christoph Hellwig
2022-11-14 10:49 ` Jan Kara
2022-11-16 16:14 ` Christoph Hellwig
2022-11-16 18:20 ` Jan Kara [this message]
2022-11-17 6:31 ` [PATCH 2/9] ext2: remove ->writepageo Christoph Hellwig
2022-11-21 10:07 ` Jan Kara
2022-11-13 16:28 ` [PATCH 3/9] fat: remove ->writepage Christoph Hellwig
2022-11-13 16:28 ` [PATCH 4/9] hfs: " Christoph Hellwig
2023-12-14 19:01 ` Matthew Wilcox
2023-12-15 4:59 ` Christoph Hellwig
2022-11-13 16:28 ` [PATCH 5/9] hfsplus: " Christoph Hellwig
2022-11-13 16:28 ` [PATCH 6/9] hpfs: " Christoph Hellwig
2022-11-13 16:29 ` [PATCH 7/9] jfs: " Christoph Hellwig
2022-11-14 14:29 ` Dave Kleikamp
2022-11-13 16:29 ` [PATCH 8/9] omfs: " Christoph Hellwig
2022-11-15 2:34 ` Bob Copeland
2022-11-13 16:29 ` [PATCH 9/9] udf: " Christoph Hellwig
2022-11-14 10:52 ` Jan Kara
2022-11-14 20:29 ` start removing writepage instances Johannes Weiner
2022-11-16 18:39 ` Ritesh Harjani (IBM)
2022-12-02 10:22 ` Christoph Hellwig
2022-11-17 21:39 ` David Howells
2022-11-17 21:41 ` David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221116182040.tecis3dqejsdqnum@quack3 \
--to=jack@suse.cz \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=hirofumi@mail.parknet.co.jp \
--cc=jack@suse.com \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=linkinjeon@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-karma-devel@lists.sourceforge.net \
--cc=linux-mm@kvack.org \
--cc=me@bobcopeland.com \
--cc=mikulas@artax.karlin.mff.cuni.cz \
--cc=shaggy@kernel.org \
--cc=sj1557.seo@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox