All of lore.kernel.org
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Matheus Alves de Almeida <matheus.aalmeida@inf.ufrgs.br>
Cc: linux-fsdevel@vger.kernel.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] fat: preallocate space before expanding in fat_cont_expand()
Date: Sat, 24 Oct 2026 08:48:44 +0900	[thread overview]
Message-ID: <877bj8q8pv.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <atvPYonyGRdK05zr@DESKTOP-PJTTJ93.localdomain>

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

> On Fri, Oct 23, 2026 at 04:33:23PM +0900, OGAWA Hirofumi wrote:
>>Matheus Alves de Almeida <matheus.aalmeida@inf.ufrgs.br> writes:
>>
>>> The fat_cont_expand() implementation leaves allocation of new clusters
>>> to generic_cont_expand_simple(). This path does many small cluster
>>> allocations, harming performance.
>>>
>>> Preallocate cluster space in fat_cont_expand(). Move preallocation to
>>> a new fat_preallocate() helper used by both fat_cont_expand() and
>>> fat_fallocate(FALLOC_FL_KEEP_SIZE).
>>>
>>> Benchmarking was done under QEMU/KVM with a virtio-blk device using
>>> cache=none. Each result is the arithmetic mean of the listed samples.
>>>
>>> start = now_ns();
>>> for (unsigned i = 0; i < count; i++) {
>>>     if (truncate_mode)
>>>         ftruncate(fds[i], bytes);
>>>     else
>>>         fallocate(fds[i], 0, 0, bytes);
>>> }
>>> elapsed = now_ns() - start;
>>>
>>> 16 files, 512-byte clusters:
>>> length    mode      sync?    before    after    improvement    samples
>>> 256MiB    ftruncate no       9.576s    5.345s   1.79x          10
>>> 256MiB    fallocate no       9.634s    5.640s   1.71x          10
>>> 1MiB      ftruncate yes      58.66s    0.362s   162.15x        5
>>> 1MiB      fallocate yes      61.36s    0.390s   157.15x        5
>>>
>>> 128 files, 512-byte clusters:
>>> length    mode      sync?    before    after    improvement    samples
>>> 512KiB    ftruncate no       0.433s    0.352s   1.23x          10
>>> 512KiB    fallocate no       0.446s    0.393s   1.13x          10
>>> 64KiB     ftruncate yes      31.32s    0.429s   73.00x         10
>>> 64KiB     fallocate yes      29.59s    0.410s   72.42x         10
>>>
>>> 16 files, 4096-byte clusters:
>>> length    mode      sync?    before    after    improvement    samples
>>> 256MiB    ftruncate no       5.181s    4.417s   1.17x          10
>>> 256MiB    fallocate no       5.166s    4.442s   1.16x          10
>>> 1MiB      ftruncate yes      9.294s    0.111s   84.06x         10
>>> 1MiB      fallocate yes      8.710s    0.110s   79.36x         10
>>>
>>> The biggest improvement is on filesystems with a small cluster size and
>>> on synchronous mounts.
>>>
>>> Signed-off-by: Matheus Alves de Almeida <matheus.aalmeida@inf.ufrgs.br>
>>> ---
>>>
>>> Changes in v2:
>>> - fat_cont_expand(): Hold truncate_lock around fat_truncate_blocks().
>>>
>>> This patch depends on:
>>> https://lore.kernel.org/linux-fsdevel/20261012171106.146243-1-matheus.aalmeida@inf.ufrgs.br/T/#t
>>>
>>>  fs/fat/file.c | 56 ++++++++++++++++++++++++++++++++++-----------------
>>>  1 file changed, 37 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/fs/fat/file.c b/fs/fat/file.c
>>> index 3aa541c6b127..dd0ae795dc14 100644
>>> --- a/fs/fat/file.c
>>> +++ b/fs/fat/file.c
>>> @@ -217,15 +217,50 @@ const struct file_operations fat_file_operations = {
>>>  	.setlease	= generic_setlease,
>>>  };
>>>  
>>> +static int fat_preallocate(struct inode *inode, loff_t new_size)
>>> +{
>>> +	int nr_cluster; /* Number of clusters to be allocated */
>>> +	loff_t mm_bytes; /* Number of bytes to be allocated for file */
>>> +	loff_t ondisksize; /* block aligned on-disk size in bytes*/
>>> +	struct super_block *sb = inode->i_sb;
>>> +	struct msdos_sb_info *sbi = MSDOS_SB(sb);
>>> +
>>> +	ondisksize = inode->i_blocks << 9;
>>> +	if (new_size <= ondisksize)
>>> +		return 0;
>>> +
>>> +	/* First compute the number of clusters to be allocated */
>>> +	mm_bytes = new_size - ondisksize;
>>> +	nr_cluster = (mm_bytes + (sbi->cluster_size - 1)) >>
>>> +		     sbi->cluster_bits;
>>> +
>>> +	/* Allocate the clusters. We are not zeroing them out */
>>> +	return fat_add_clusters(inode, nr_cluster);
>>> +}
>>> +
>>>  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?
>>
> Yes. generic_cont_expand_simple() calls inode_newsize_ok() as well,
> which happens before fat_write_failed() can run and clean up. Another
> thread could lower RLIMIT_FSIZE between the FAT and generic checks and
> return without cleaning up.

If the reason is only for inode_newsize_ok(), we would be able to add
fat_cont_expand_simple() or such instead.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

      reply	other threads:[~2026-10-23 23:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-21 15:40 [PATCH v2] fat: preallocate space before expanding in fat_cont_expand() Matheus Alves de Almeida
2026-10-23  7:33 ` OGAWA Hirofumi
2026-10-23 15:44   ` OGAWA Hirofumi
2026-10-23 21:23     ` Matheus Alves de Almeida
2026-10-24  0:06       ` OGAWA Hirofumi
2026-10-23 21:21   ` Matheus Alves de Almeida
2026-10-23 23:48     ` OGAWA Hirofumi [this message]

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=877bj8q8pv.fsf@mail.parknet.co.jp \
    --to=hirofumi@mail.parknet.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matheus.aalmeida@inf.ufrgs.br \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.