[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z2mWf-pghAlHYJ8o@google.com>
Date: Mon, 23 Dec 2024 16:57:35 +0000
From: Jaegeuk Kim <jaegeuk@...nel.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: Daniel Lee <chullee@...gle.com>, Chao Yu <chao@...nel.org>,
linux-f2fs-devel@...ts.sourceforge.net,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] f2fs: Introduce linear search for dentries
On 12/23, Christoph Hellwig wrote:
> On Fri, Dec 20, 2024 at 09:21:36AM -0800, Daniel Lee wrote:
> > This patch addresses an issue where some files in case-insensitive
> > directories become inaccessible due to changes in how the kernel function,
> > utf8_casefold(), generates case-folded strings from the commit 5c26d2f1d3f5
> > ("unicode: Don't special case ignorable code points").
>
> That also breaks all other direct hashed and needs to be fixed.
>
> >
> > F2FS uses these case-folded names to calculate hash values for locating
> > dentries and stores them on disk. Since utf8_casefold() can produce
> > different output across kernel versions, stored hash values and newly
> > calculated hash values may differ. This results in affected files no
> > longer being found via the hash-based lookup.
> >
> > To resolve this, the patch introduces a linear search fallback.
> > If the initial hash-based search fails, F2FS will sequentially scan the
> > directory entries.
>
> That means you have really bad worst case behavior for negative lookups.
> I don' think this is in any way a good idea.
No surprise. Please check:
https://lore.kernel.org/lkml/Z1mzu4Eg6CPURra3@google.com/
Powered by blists - more mailing lists