All of lore.kernel.org
 help / color / mirror / Atom feed
From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Matheus Alves de Almeida <matheus.aalmeida@inf.ufrgs.br>,
	linux-fsdevel@vger.kernel.org,  linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/3] fat: allocate multiple clusters in fallocate
Date: Tue, 13 Oct 2026 22:17:50 +0900	[thread overview]
Message-ID: <87cxtdn3i9.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <20261012171106.146243-4-matheus.aalmeida@inf.ufrgs.br>

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

> The fat_fallocate() code currently does many 1-cluster allocations when
> growing a file in the FALLOC_FL_KEEP_SIZE path. Make it allocate
> everything with one call instead.
>
> 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 int i = 0; i < count; i++)
>      fallocate(fds[i], FALLOC_FL_KEEP_SIZE, 0, bytes);
> elapsed = now_ns() - start;
>
> FAT32 with 512-byte clusters using count=16 files:
> length    mounted sync?    before    after    improvement    samples
> 256MiB    no               2.328s    0.175s   13.2x          10
> 16MiB     no               149.659ms 14.036ms 10.7x          10
> 16MiB     yes              747.993s  3.445s   217.1x         3
> 1MiB      yes              46.63s    0.333s   140.1x         10
>
> FAT32 with 512-byte clusters using count=128 files:
> length    mounted sync?    before    after    improvement    samples
> 1MiB      no               90.873ms  4.686ms  19.4x          10
> 16KiB     no               1.287ms   0.241ms  5.3x           10
> 128KiB    yes              47.284s   0.350s   135x           10
> 4KiB      yes              1.98s     0.144s   13.7x          10
>
> FAT32 with 4096-byte clusters using count=16 files:
> length    mounted sync?    before    after    improvement    samples
> 256MiB    no               295.392ms 24.733ms 11.9x          10
> 16MiB     no               20.509ms  1.404ms  14.6x          10
> 16MiB     yes              92.489s   0.348s   265.4x         10
> 1MiB      yes              5.837s    0.048s   121.3x         10
>
> The improvement is especially large on synchronous mounts, where the
> new code can batch FAT updates instead of synchronously handling each
> cluster allocation separately.
>
> Signed-off-by: Matheus Alves de Almeida <matheus.aalmeida@inf.ufrgs.br>

Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

Looks good. Thanks.

> ---
>  fs/fat/file.c | 10 ++++------
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/fs/fat/file.c b/fs/fat/file.c
> index 41d49e9de..3aa541c6b 100644
> --- a/fs/fat/file.c
> +++ b/fs/fat/file.c
> @@ -290,12 +290,10 @@ static long fat_fallocate(struct file *file, int mode,
>  		nr_cluster = (mm_bytes + (sbi->cluster_size - 1)) >>
>  			sbi->cluster_bits;
>  
> -		/* Start the allocation.We are not zeroing out the clusters */
> -		while (nr_cluster-- > 0) {
> -			err = fat_add_clusters(inode, 1);
> -			if (err)
> -				goto error;
> -		}
> +		/* Allocate the clusters. We are not zeroing them out */
> +		err = fat_add_clusters(inode, nr_cluster);
> +		if (err)
> +			goto error;
>  	} else {
>  		if ((offset + len) <= i_size_read(inode))
>  			goto error;

-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>

      reply	other threads:[~2026-10-13 13:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12 17:11 [PATCH v2 0/3] fat: allocate multiple clusters in fallocate Matheus Alves de Almeida
2026-10-12 17:11 ` [PATCH v2 1/3] fat: remove cluster allocation size limit Matheus Alves de Almeida
2026-10-13 13:17   ` OGAWA Hirofumi
2026-10-12 17:11 ` [PATCH v2 2/3] fat: support adding multiple clusters Matheus Alves de Almeida
2026-10-13 13:17   ` OGAWA Hirofumi
2026-10-12 17:11 ` [PATCH v2 3/3] fat: allocate multiple clusters in fallocate Matheus Alves de Almeida
2026-10-13 13:17   ` 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=87cxtdn3i9.fsf@mail.parknet.co.jp \
    --to=hirofumi@mail.parknet.co.jp \
    --cc=akpm@linux-foundation.org \
    --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.