All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.