Re: [PATCH v2 3/4] exfat: dirty all new pages when extending valid_size

From: Chi Zhiling

Date: Tue Oct 06 2026 - 08:48:10 EST


On 10/6/26 2:30 PM, Namjae Jeon wrote:
On Tue, Oct 6, 2026 at 3:02 PM Chi Zhiling <chizhiling@xxxxxxx> wrote:

On 10/6/26 11:57 AM, Namjae Jeon wrote:
On Mon, Oct 5, 2026 at 7:19 PM Chi Zhiling <chizhiling@xxxxxxx> wrote:

On 10/5/26 5:08 PM, Namjae Jeon wrote:
@@ -664,90 +664,30 @@ int exfat_file_fsync(struct file *filp, loff_t start, loff_t end, int datasync)
static int exfat_zero_new_range(struct inode *inode, loff_t start, loff_t end)
Function name and comments no longer seem to match. What do you think
about changing them like this?

/*
* exfat_prepare_valid_range - populate and dirty folios covering [start, end)
*
* Populate missing blocks via the read path, which zero-fills data
* beyond the current valid_size while preserving uptodate blocks.
* Mark entire folios dirty so the newly valid range is written back.
*
* Call before advancing valid_size.
*/

Okay, I'll add it to v3.


And generic/538 test fails with this patch set. Please check if this
test failure is reproducible for you as well.

I ran the tests, but I wasn't able to reproduce the failure. Could you
tell me the block size and cluster size used to reproduce it?

There is also a new failure in generic/551. This failure can be fixed by
adding inode_dio_wait() to exfat_extend_valid_size(). Jiale's patch
includes this fix:

https://lore.kernel.org/exfat/20261003093035.532916-4-yaojiale02@xxxxxxx/T/#u
Okay, generic/538 test passed with this patch.
I will apply this patch and your patch-set.

Okay,

I noticed that these patches have already been merged into the exfat/dev
branch, and the comments in exfat_zero_new_range() have also been
updated. So I don't need to send v3, right?
For now, yes. I am currently doing other tests, and if there are some
issues for these patches, I will request v3 to you.

Okay!