From: Zhang Yi <yi.zhang@huaweicloud.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christoph Hellwig <hch@infradead.org>,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, djwong@kernel.org,
brauner@kernel.org, david@fromorbit.com, jack@suse.cz,
yi.zhang@huawei.com, chengzhihao1@huawei.com, yukuai3@huawei.com
Subject: Re: [PATCH v2 3/6] iomap: advance the ifs allocation if we have more than one blocks per folio
Date: Sat, 17 Aug 2024 14:16:30 +0800 [thread overview]
Message-ID: <73a60117-79c2-fa69-2113-1932a644363f@huaweicloud.com> (raw)
In-Reply-To: <ZsAqG-Q527PYWYrz@casper.infradead.org>
On 2024/8/17 12:42, Matthew Wilcox wrote:
> On Sat, Aug 17, 2024 at 12:27:49PM +0800, Zhang Yi wrote:
>> On 2024/8/14 13:32, Christoph Hellwig wrote:
>>> On Mon, Aug 12, 2024 at 08:11:56PM +0800, Zhang Yi wrote:
>>>> From: Zhang Yi <yi.zhang@huawei.com>
>>>>
>>>> Now we allocate ifs if i_blocks_per_folio is larger than one when
>>>> writing back dirty folios in iomap_writepage_map(), so we don't attach
>>>> an ifs after buffer write to an entire folio until it starts writing
>>>> back, if we partial truncate that folio, iomap_invalidate_folio() can't
>>>> clear counterpart block's dirty bit as expected. Fix this by advance the
>>>> ifs allocation to __iomap_write_begin().
>>>
>>> Wouldn't it make more sense to only allocate the ifѕ in
>>> iomap_invalidate_folio when it actually is needed?
>>>
>>
>> I forget to mention that truncate_inode_partial_folio() call
>> folio_invalidate()->iomap_invalidate_folio() only when the folio has
>> private, if the folio doesn't has ifs, the iomap_invalidate_folio()
>> would nerver be called, hence allocate the ifs in
>> iomap_invalidate_folio() is useless.
>>
>> In my opinion, one solution is change to always call folio_invalidate()
>> in truncate_inode_partial_folio(), all callbacks should handle the no
>> private case. Another solution is add a magic (a fake ifs) to
>> folio->private and then convert it to a real one in
>> iomap_invalidate_folio(), any thoughts?
>
> Why do we need iomap_invalidate_folio() to be called if there is no ifs?
> Even today, all it does is call ifs_free() if we're freeing the entire
> folio (which is done by truncate_cleanup_folio() and not by
> truncate_inode_partial_folio().
>
Please see patch 2, if we truncate a partial folio (through punch hole or
truncate) on a filesystem with blocksize < folio size, it will left over
dirty bits of truncated/punched blocks, and this will lead to a hole with
dirty bit set but without any block allocated/reserved, this is not
correct.
Hence we also need to call iomap_invalidate_folio() by
truncate_inode_partial_folio() and clear partial folio of the counterpart
dirty bits. But now we don't allocate ifs in __iomap_write_begin() when
writing an entire folio, so it doesn't has ifs, but we still can
partial truncate this folio, we should allocate ifs for it and update
the dirty bits on it.
Thanks,
Yi.
next prev parent reply other threads:[~2024-08-17 6:16 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 12:11 [PATCH v2 0/6] iomap: some minor non-critical fixes and improvements when block size < folio size Zhang Yi
2024-08-12 12:11 ` [PATCH v2 1/6] iomap: correct the range of a partial dirty clear Zhang Yi
2024-08-12 16:33 ` Darrick J. Wong
2024-08-13 2:14 ` Zhang Yi
2024-08-14 1:53 ` Dave Chinner
2024-08-12 12:11 ` [PATCH v2 2/6] iomap: support invalidating partial folios Zhang Yi
2024-08-12 16:55 ` Darrick J. Wong
2024-08-12 12:11 ` [PATCH v2 3/6] iomap: advance the ifs allocation if we have more than one blocks per folio Zhang Yi
2024-08-12 12:47 ` yangerkun
2024-08-13 2:21 ` Zhang Yi
2024-08-14 5:32 ` Christoph Hellwig
2024-08-14 7:08 ` Zhang Yi
2024-08-15 6:00 ` Christoph Hellwig
2024-08-16 1:44 ` Zhang Yi
2024-08-17 4:27 ` Zhang Yi
2024-08-17 4:42 ` Matthew Wilcox
2024-08-17 6:16 ` Zhang Yi [this message]
2024-08-12 12:11 ` [PATCH v2 4/6] iomap: correct the dirty length in page mkwrite Zhang Yi
2024-08-12 16:45 ` Darrick J. Wong
2024-08-13 2:49 ` Zhang Yi
2024-08-14 5:36 ` Christoph Hellwig
2024-08-14 7:49 ` Zhang Yi
2024-08-15 5:59 ` Christoph Hellwig
2024-08-16 2:19 ` Zhang Yi
2024-08-17 4:45 ` Matthew Wilcox
2024-08-17 6:43 ` Zhang Yi
2024-08-12 12:11 ` [PATCH v2 5/6] iomap: don't mark blocks uptodate after partial zeroing Zhang Yi
2024-08-12 16:49 ` Darrick J. Wong
2024-08-13 3:01 ` Zhang Yi
2024-08-14 5:39 ` Christoph Hellwig
2024-08-17 4:48 ` Matthew Wilcox
2024-08-17 7:16 ` Zhang Yi
2024-08-12 12:11 ` [PATCH v2 6/6] iomap: reduce unnecessary state_lock when setting ifs uptodate and dirty bits Zhang Yi
2024-08-12 16:54 ` Darrick J. Wong
2024-08-12 17:00 ` Matthew Wilcox
2024-08-13 8:15 ` Zhang Yi
2024-08-14 1:49 ` [PATCH v2 0/6] iomap: some minor non-critical fixes and improvements when block size < folio size Dave Chinner
2024-08-14 2:14 ` Zhang Yi
2024-08-14 2:47 ` Dave Chinner
2024-08-14 3:57 ` Zhang Yi
2024-08-14 5:16 ` Dave Chinner
2024-08-14 6:32 ` Zhang Yi
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=73a60117-79c2-fa69-2113-1932a644363f@huaweicloud.com \
--to=yi.zhang@huaweicloud.com \
--cc=brauner@kernel.org \
--cc=chengzhihao1@huawei.com \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=willy@infradead.org \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.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;
as well as URLs for NNTP newsgroup(s).