Re: [PATCH v2] fat: preallocate space before expanding in fat_cont_expand()

[Matheus Alves de Almeida]

On Sat, Oct 24, 2026 at 12:44:04AM +0900, OGAWA Hirofumi wrote:
>OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> writes:
>
>>>  static int fat_cont_expand(struct inode *inode, loff_t size)
>>>  {
>>>  	struct address_space *mapping = inode->i_mapping;
>>>  	loff_t start = inode->i_size, count = size - inode->i_size;
>>>  	int err;
>>>  
>>> -	err = generic_cont_expand_simple(inode, size);
>>> +	/*
>>> +	 * Preallocating space here is more efficient than during
>>> +	 * generic_cont_expand_simple() because of batching.
>>> +	 */
>>> +	err = inode_newsize_ok(inode, size);
>>>  	if (err)
>>>  		goto out;
>>> +	err = fat_preallocate(inode, size);
>>> +	if (err)
>>> +		goto out;
>>> +	err = generic_cont_expand_simple(inode, size);
>>> +	if (err) {
>>> +		down_write(&MSDOS_I(inode)->truncate_lock);
>>> +		fat_truncate_blocks(inode, inode->i_size);
>>> +		up_write(&MSDOS_I(inode)->truncate_lock);
>>
>> Is this fat_truncate_blocks() really required?
>>
>>> +		goto out;
>>> +	}
>
>And maybe this will change the user visible behavior for ENOSPC. (I'm
>not sure if it is ok for now)
>
>Thanks.
>-- 
>OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>

The behavior on a fallocate() ENOSPC failure seems to differ across
filesystems, some (e.g. exFAT, NTFS3) keep the original size while others
(e.g. ext4) keep the partially extended size.

If preserving the current FAT behavior is preferred, I can look into that
for a v3. Maybe adding a new fat_try_alloc_chain() helper that allocates
as many clusters as it can instead of failing the entire allocation.

What do you think?

Thanks,
Matheus