Re: [PATCH v2 3/4] exfat: dirty all new pages when extending valid_size
From: Chi Zhiling
Date: Tue Oct 06 2026 - 02:04:54 EST
On 10/6/26 11:57 AM, Namjae Jeon wrote:
On Mon, Oct 5, 2026 at 7:19 PM Chi Zhiling <chizhiling@xxxxxxx> wrote:
Okay, generic/538 test passed with this patch.
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)Function name and comments no longer seem to match. What do you think
static int exfat_zero_new_range(struct inode *inode, loff_t start, loff_t end)
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
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?