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

[OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>]

Matheus Alves de Almeida <matheus.aalmeida@inf.ufrgs.br> writes:

> On Sat, Oct 24, 2026 at 12:44:04AM +0900, OGAWA Hirofumi wrote:
>>OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> 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@mail.parknet.co.jp>
>
> 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?

fallocate() or expand truncate() path. Hm, well, we can try to change
the error behavior (if failed, revert then).
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>