From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-ext4@vger.kernel.org, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org
Subject: Re: [RFC 2/3] ext2: Convert ext2 regular file buffered I/O to use iomap
Date: Thu, 23 Nov 2023 01:55:27 +0530 [thread overview]
Message-ID: <87pm01r0w8.fsf@doe.com> (raw)
In-Reply-To: <20231122122946.wg3jqvem6fkg3tgw@quack3>
Jan Kara <jack@suse.cz> writes:
> On Tue 21-11-23 00:35:20, Ritesh Harjani (IBM) wrote:
>> This patch converts ext2 regular file's buffered-io path to use iomap.
>> - buffered-io path using iomap_file_buffered_write
>> - DIO fallback to buffered-io now uses iomap_file_buffered_write
>> - writeback path now uses a new aops - ext2_file_aops
>> - truncate now uses iomap_truncate_page
>> - mmap path of ext2 continues to use generic_file_vm_ops
>>
>> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>
> Looks nice and simple. Just one comment below:
>
>> +static void ext2_file_readahead(struct readahead_control *rac)
>> +{
>> + return iomap_readahead(rac, &ext2_iomap_ops);
>> +}
>
> As Matthew noted, the return of void here looks strange.
>
yes, I will fix it.
>> +static int ext2_write_map_blocks(struct iomap_writepage_ctx *wpc,
>> + struct inode *inode, loff_t offset)
>> +{
>> + if (offset >= wpc->iomap.offset &&
>> + offset < wpc->iomap.offset + wpc->iomap.length)
>> + return 0;
>> +
>> + return ext2_iomap_begin(inode, offset, inode->i_sb->s_blocksize,
>> + IOMAP_WRITE, &wpc->iomap, NULL);
>> +}
>
> So this will end up mapping blocks for writeback one block at a time if I'm
> understanding things right because ext2_iomap_begin() never sets extent
> larger than 'length' in the iomap result. Hence the wpc checking looks
> pointless (and actually dangerous - see below). So this will probably get
> more expensive than necessary by calling into ext2_get_blocks() for each
> block? Perhaps we could first call ext2_iomap_begin() for reading with high
> length to get as many mapped blocks as we can and if we find unmapped block
> (should happen only for writes through mmap), we resort to what you have
> here... Hum, but this will not work because of the races with truncate
> which could remove blocks whose mapping we have cached in wpc. We can
> safely provide a mapping under a folio only once it is locked or has
> writeback bit set. XFS plays the revalidation sequence counter games
> because of this so we'd have to do something similar for ext2. Not that I'd
> care as much about ext2 writeback performance but it should not be that
> hard and we'll definitely need some similar solution for ext4 anyway. Can
> you give that a try (as a followup "performance improvement" patch).
>
Yes, looking into ->map_blocks was on my todo list, since this RFC only
maps 1 block at a time which can be expensive. I missed adding that as a
comment in cover letter.
But also thanks for providing many details on the same. I am taking a
look at it and will get back with more details on how can we get this
working, as it will be anyway required for ext4 too.
-ritesh
next prev parent reply other threads:[~2023-11-22 20:25 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1700506526.git.ritesh.list@gmail.com>
2023-11-20 19:05 ` [RFC 1/3] ext2: Fix ki_pos update for DIO buffered-io fallback case Ritesh Harjani (IBM)
2023-11-21 4:39 ` Christoph Hellwig
2023-11-21 5:36 ` Ritesh Harjani
2023-11-22 6:51 ` Christoph Hellwig
2023-11-20 19:05 ` [RFC 2/3] ext2: Convert ext2 regular file buffered I/O to use iomap Ritesh Harjani (IBM)
2023-11-20 20:00 ` Matthew Wilcox
2023-11-21 4:44 ` Christoph Hellwig
2023-11-21 5:56 ` Ritesh Harjani
2023-11-21 6:08 ` Christoph Hellwig
2023-11-21 6:15 ` Ritesh Harjani
2023-11-22 12:29 ` Jan Kara
2023-11-22 13:11 ` Christoph Hellwig
2023-11-22 20:26 ` Ritesh Harjani
2023-11-30 3:24 ` Ritesh Harjani
2023-11-30 4:22 ` Matthew Wilcox
2023-11-30 4:37 ` Ritesh Harjani
2023-11-30 4:30 ` Christoph Hellwig
2023-11-30 5:27 ` Ritesh Harjani
2023-11-30 8:22 ` Zhang Yi
2023-11-30 7:45 ` Ritesh Harjani
2023-11-30 10:18 ` Jan Kara
2023-11-30 10:59 ` Ritesh Harjani
2023-11-30 14:08 ` Jan Kara
2023-11-30 15:50 ` Ritesh Harjani
2023-11-30 16:01 ` Jan Kara
2023-11-30 16:03 ` Matthew Wilcox
2023-12-01 23:09 ` Dave Chinner
2023-12-05 15:22 ` Ritesh Harjani
2023-12-07 8:58 ` Jan Kara
2023-11-22 22:26 ` Dave Chinner
2023-11-23 4:09 ` Darrick J. Wong
2023-11-23 7:09 ` Christoph Hellwig
2023-11-29 5:37 ` Darrick J. Wong
2023-11-29 6:32 ` Christoph Hellwig
2023-11-29 9:19 ` Dave Chinner
2023-11-23 7:02 ` Christoph Hellwig
2023-11-22 20:25 ` Ritesh Harjani [this message]
2023-11-20 19:05 ` [RFC 3/3] ext2: Enable large folio support Ritesh Harjani (IBM)
2023-11-20 20:00 ` Matthew Wilcox
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=87pm01r0w8.fsf@doe.com \
--to=ritesh.list@gmail.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
/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