Re: [PATCH v2] exfat: speed up file creation in large directories

From: Chi Zhiling

Date: Tue Sep 01 2026 - 03:52:30 EST


On 8/31/26 11:15 PM, Yang Wen wrote:
Negative name lookups scan a directory from the beginning. Repeating
this scan before creating each file makes bulk file creation approach
O(N^2).

Add a 64 KiB per-directory Bloom filter and retain the next empty entry
found during directory scans. A definite Bloom filter miss skips the
directory scan, while a possible match falls back to the normal lookup
path, preserving correctness in the presence of hash collisions.

To avoid overhead for small directories, build the filter lazily when a
directory reaches 1024 on-disk directory entries. A filter reclaimed
under memory pressure is rebuilt on demand.

Manage the filters using a per-superblock LRU and shrinker so that filters
for inactive directories can be reclaimed under memory pressure.

Test environment:
QEMU TCG multi-thread, 4 vCPUs, 6 GiB RAM
4 GiB exFAT image, 32 KiB clusters

Test script:
mount -t exfat /dev/vda /mnt/test
time sh -c '
i=0
while [ "$i" -lt 20000 ]; do
: > "/mnt/test/f.$i" || exit 1
i=$((i + 1))
done
'

The measured results were:

Before After
real 589.48 s 5.33 s
user 4.72 s 2.28 s
sys 584.63 s 3.03 s

The elapsed time was reduced by 99.10%, from 589.48 seconds to
5.33 seconds, corresponding to a 110.6-fold speedup.

Signed-off-by: Yang Wen <anmuxixixi@xxxxxxxxx>
---

Changes in v2:
- Move exfat_name_filter_free() from exfat_free_inode() to
exfat_evict_inode(), after truncate_inode_pages_final(), because
->free_inode() may run from an RCU callback in softirq context.
- Link to v1: https://lore.kernel.org/all/20260828145838.1187356-1-anmuxixixi@xxxxxxxxx/
---
fs/exfat/dir.c | 280 ++++++++++++++++++++++++++++++++++++++++++++
fs/exfat/exfat_fs.h | 22 ++++
fs/exfat/inode.c | 1 +
fs/exfat/namei.c | 44 ++++++-
fs/exfat/super.c | 9 ++
5 files changed, 355 insertions(+), 1 deletion(-)

This is a fairly large patch, which makes the review a bit more
challenging. Perhaps next time you could consider splitting it into
multiple patches in a patch series :)

Reviewed-by: Chi Zhiling <chizhiling@xxxxxxxxxx>