mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Sungjong Seo" <sj1557.seo@samsung.com>
To: "'Yang Wen'" <anmuxixixi@gmail.com>, <linkinjeon@kernel.org>
Cc: <yuezhang.mo@sony.com>, <linux-fsdevel@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <cpgs@samsung.com>,
	<sj1557.seo@samsung.com>, <sjdev.seo@gmail.com>
Subject: RE: [PATCH v2 0/1] exfat: reduce directory scans during file creation
Date: Sun, 14 Jun 2026 18:41:14 +0900	[thread overview]
Message-ID: <000001dcfbe1$f1341d10$d39c5730$@samsung.com> (raw)
In-Reply-To: <20260613133856.238740-1-anmuxixixi@gmail.com>

> Creating files in a large exfat directory may require repeated linear
> directory scans.
> 
> After an empty-entry hint is used successfully, the remaining contiguous
> empty entries are not retained for the next create operation.
> This can cause subsequent operations to rediscover available directory
> space.
> 
> In a test creating 20,000 files with random names and sizes between 1 KiB
> and 4 KiB in one directory, the elapsed time changed as follows:
> 
>   Before: 3879 seconds
>   After:  3050 seconds
Hello, Yang Wen,

As Namjae reviewed, we intentionally drop the dentry in LOOKUP_CREATE to
maintain the case of newly created filenames. Therefore, when creating
a new file, a brute-force search of the entire directory is required,
and the hint value is naturally updated during this process.

For this reason, I believe this current patch will not improve performance
and is an unnecessary operation. Is there any performance gain with the
current patch, excluding the dropped part?

> 
> ---
> 
> Changes since v1:
> - Drop the LOOKUP_CREATE negative dentry change.
> - Make exfat_cache_next_empty_entry() return void and skip caching if
>   exfat_chain_advance() fails.
> 
> Yang Wen (1):
>   exfat: preserve the next empty-entry hint after allocation
> 
>  fs/exfat/namei.c | 39 +++++++++++++++++++++++++++++++++++++--
>  1 file changed, 37 insertions(+), 2 deletions(-)
> 
> --
> 2.34.1



      reply	other threads:[~2026-06-14  9:41 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20260613133917epcas1p183cb2d5b2c82fa1651a96364cd8efda8@epcas1p1.samsung.com>
2026-06-13 13:38 ` Yang Wen
2026-06-14  9:41   ` Sungjong Seo [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='000001dcfbe1$f1341d10$d39c5730$@samsung.com' \
    --to=sj1557.seo@samsung.com \
    --cc=anmuxixixi@gmail.com \
    --cc=cpgs@samsung.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sjdev.seo@gmail.com \
    --cc=yuezhang.mo@sony.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome