[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <lskt5tzoqnklkezad2rsqs5ezitmrn4vyppwlwrcusasebkaea@qtdmnqyusunk>
Date: Sun, 27 Apr 2025 23:29:14 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Matthew Wilcox <willy@...radead.org>, Theodore Ts'o <tytso@....edu>,
Linus Torvalds <torvalds@...ux-foundation.org>, linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] bcachefs fixes for 6.15-rc4
On Sun, Apr 27, 2025 at 07:49:45PM -0700, Eric Biggers wrote:
> Is there a reason why you don't just do what ext4 and f2fs does and store (only)
> the case-preserved original name on-disk?
The rationale was performance.
In hindsight I think that made zero sense, but perhaps it will turn out
to be useful in a way - because that's what got me thinking about
compatibility more, and then "separate indexes for casefolded and non
casefolded".
I'm not sure that this is honestly pressing enough that we'll write the
code, but that is feeling like the actual correct approach here.
>
> Note that generic_ci_match() has a fast path that compares the bytes of the
> on-disk name to the bytes of the user-requested name. Only if they don't match
> is the "casefolded" comparison done. It's true that if the filesystem were to
> store the "casefolded" name on-disk too, then it wouldn't have to be computed
> for each "casefolded" comparison with that dentry. But that's already the "slow
> path" that is executed only when the name wasn't case-sensitively the same.
Yeah, and all this is only hit on dcache misses, which makes it pretty
irrelevant.
Powered by blists - more mailing lists