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 0/4] fat: allocate multiple clusters in fallocate
Date: Mon, 12 Oct 2026 15:01:01 +0900	[thread overview]
Message-ID: <87se2blaoy.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <3b0bef1504539358bf049724329ced57@inf.ufrgs.br>

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

> Em 2026-10-11 15:55, OGAWA Hirofumi escreveu:
>> Matheus Alves de Almeida <matheus.aalmeida@inf.ufrgs.br> writes:
>> 
>>> Hi,
>
>>> This series adds support for allocating multiple clusters in a single
>>> fat_add_clusters() call in fat_fallocate().
>
>>> The multi-cluster TODO in inode.c is not implemented, as doing so would
>>> require speculative preallocation or an iomap conversion.
>
>> Is this to improve the performance of fallocate? If so, what the number
>> by improved bench or such?
>
> Yes, it is. I ran a few benchmarks. Each run used a freshly formatted
> filesystem, with no userspace processes other than init (which is the
> benchmark program in this case).
>
> The numbers below are the arithmetic mean of the samples, with
> improvement calculated as before / after. The times are for the complete
> loop and not an individual fallocate() call.
>
> The benchmarks were run under QEMU/KVM with a virtio-blk device using
> cache=none.
>
> 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
>
> * it would take a lot of time to take 10 samples like the others,
>    so I only took 3 here.
>
> The improvement is large because the old fallocate path allocates one
> cluster at a time, while the new path can allocate an entire chain in
> one call. This is especially visible on synchronous mounts, where the
> new code can batch FAT updates instead of synchronously handling each
> cluster allocation separately.

Thank you. Please add it to the commit log too.

> Thanks,
> Matheus
>
>>> Matheus Alves de Almeida (4):
>>>  fat: remove cluster allocation size limit
>>>  fat: return only first cluster when allocating
>>>  fat: support adding multiple clusters
>>>  fat: allocate multiple clusters in fallocate
>>> 
>>> fs/fat/dir.c    | 20 +++++++++++++++-
>>> fs/fat/fat.h    |  4 ++--
>>> fs/fat/fatent.c | 61 ++++++++++++++++++++++++++++++++-----------------
>>> fs/fat/file.c   | 10 ++++----
>>> fs/fat/inode.c  |  8 +++----
>>> 5 files changed, 69 insertions(+), 34 deletions(-)
>

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

      reply	other threads:[~2026-10-12  6:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08  2:09 [PATCH 0/4] fat: allocate multiple clusters in fallocate Matheus Alves de Almeida
2026-10-08  2:09 ` [PATCH 1/4] fat: remove cluster allocation size limit Matheus Alves de Almeida
2026-10-08  2:09 ` [PATCH 2/4] fat: return only first cluster when allocating Matheus Alves de Almeida
2026-10-11 18:57   ` OGAWA Hirofumi
2026-10-12  5:44     ` Matheus Alves de Almeida
2026-10-12  6:03       ` OGAWA Hirofumi
2026-10-08  2:09 ` [PATCH 3/4] fat: support adding multiple clusters Matheus Alves de Almeida
2026-10-08  2:09 ` [PATCH 4/4] fat: allocate multiple clusters in fallocate Matheus Alves de Almeida
2026-10-11 18:55 ` [PATCH 0/4] " OGAWA Hirofumi
2026-10-12  5:43   ` Matheus Alves de Almeida
2026-10-12  6:01     ` 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=87se2blaoy.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.