Message-ID: <ogtnxaeyjldd6lapfbhwj3ptpvwkjpn66e3gejawdjs7s7hg2v@pksyrq3gzwal>
Date: Sun, 27 Apr 2025 22:33:29 -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:15:14PM -0700, Eric Biggers wrote:
> On Sun, Apr 27, 2025 at 09:43:43PM -0400, Kent Overstreet wrote:
> > On Sun, Apr 27, 2025 at 06:30:59PM -0700, Eric Biggers wrote:
> > > On Sun, Apr 27, 2025 at 08:55:30PM -0400, Kent Overstreet wrote:
> > > > The thing is, that's exactly what we're doing. ext4 and bcachefs both
> > > > refer to a specific revision of the folding rules: for ext4 it's
> > > > specified in the superblock, for bcachefs it's hardcoded for the moment.
> > > > 
> > > > I don't think this is the ideal approach, though.
> > > > 
> > > > That means the folding rules are "whatever you got when you mkfs'd".
> > > > Think about what that means if you've got a fleet of machines, of
> > > > different ages, but all updated in sync: that's a really annoying way
> > > > for gremlins of the "why does this machine act differently" variety to
> > > > creep in.
> > > > 
> > > > What I'd prefer is for the unicode folding rules to be transparently and
> > > > automatically updated when the kernel is updated, so that behaviour
> > > > stays in sync. That would behave more the way users would expect.
> > > > 
> > > > But I only gave this real thought just over the past few days, and doing
> > > > this safely and correctly would require some fairly significant changes
> > > > to the way casefolding works.
> > > > 
> > > > We'd have to ensure that lookups via the case sensitive name always
> > > > works, even if the casefolding table the dirent was created with give
> > > > different results that the currently active casefolding table.
> > > > 
> > > > That would require storing two different "dirents" for each real dirent,
> > > > one normalized and one un-normalized, because we'd have to do an
> > > > un-normalized lookup if the normalized lookup fails (and vice versa).
> > > > Which should be completely fine from a performance POV, assuming we have
> > > > working negative dentries.
> > > > 
> > > > But, if the unicode folding rules are stable enough (and one would hope
> > > > they are), hopefully all this is a non-issue.
> > > > 
> > > > I'd have to gather more input from users of casefolding on other
> > > > filesystems before saying what our long term plans (if any) will be.
> > > 
> > > Wouldn't lookups via the case-sensitive name keep working even if the
> > > case-insensitivity rules change?  It's lookups via a case-insensitive name that
> > > could start producing different results.  Applications can depend on
> > > case-insensitive lookups being done in a certain way, so changing the
> > > case-insensitivity rules can be risky.
> > 
> > No, because right now on a case-insensitive filesystem we _only_ do the
> > lookup with the normalized name.
> 
> Well, changing the case-insensitivity rules on an existing filesystem breaks the
> directory indexing, so when the filesystem does an indexed lookup in a directory
> it might no longer look in the right place.  But if the dentry were to be
> examined regardless, it would still match.  (Again, assuming that the lookup
> uses a name that is case-sensitively the same as the name the file was created
> with.  If it's not case-sensitively the same, that's another story.)  ext4 and
> f2fs recently added a fallback to a linear search for dentries in "casefolded"
> directories, which handle this by no longer relying solely on the directory
> indexing.  See commits 9e28059d56649 and 91b587ba79e1b.

bcachefs stores the normalized d_name, in addition to the
un-normalized version, so our low level directory indexing works just
fine if the normalization rules change.

That is, bcachefs could be changed to always load the latest unicode
normalization table, and internally everything will work completely
fine.

BUT:

If the normalization rules change for an existing dirent, then looking up
the un-normalized name with the new rules gives you a different
normalization than what's on disk and would return -ENOENT. You'd have
to look up the old normalized name, or something that normalized to the
old normalized name, to find it. Obviously, that's broken.

IOW: bcachefs doesn't have the linear search fallback, and that's not
something I'd ever add. That effectively means a silent fallback to
O(n^2) algorithms, and I don't want the bug reports that would someday
generate.

Powered by blists - more mailing lists