Re: [GIT PULL] bcachefs fixes for 6.15-rc4

["Theodore Ts'o" <tytso@mit.edu>]

The resaon why I pushed for case folding was because Android userspace
needed it, for backwards compatibiliy with previous implementationsm
(which did use FAT), and the alternative we were replacing was this
horrific wrapfs implementation which Al refused to accept because it a
mess from a locking perspective; I could trivially lock up the kernel
or cause file system corruptions using fsstress when wrapfs was in the
picture.

Another use case was Valve who wanted to support Windows games that
expcted case folding to work.  (Microsoft Windows; the gift that keeps
on giving...)  In fact the engineer who worked on case folding was
paid by Valve to do the work.

That being said, I completely agree with Linus that case insensitivity
is a nightmare, and I don't really care about performance.  The use
cases where people care about this don't have directories with a large
number of entries, and we **really** don't want to encourage more use
of case insensitive lookups.  There's a reason why spent much effort
improving the CLI tools' support for case folding.  It's good enough
that it works for Android and Valve, and that's fine.

As far as Unicode changing over time, in practice, we don't really
need to care.  Unicode has promised not to make backwards incompatible
changes; they might add new characters, for some ancient Mesopotamian
script that only some academic care about, or a new set of emoji's.
Fortunately, either the case folding tables aren't getting extended
(emoji's don't have case to be folded; the ancient sumarian script
might note have the concept of case in teh first place) or we just
don't care (even if said sumarian script did *have* case folding, it's
unlikely that a cell phone user or a Valve gamer would likely to
care).

I will readily admit that Unicode is something we didn't completely
understand; never in my worst nightmares that someone would be
silly/insane enough to add the concept of zero-width characters,
including zero-width characters that end up changing how the character
is displayed (e.g., a red heart versus a black spade differs only by
adding a zero-width selector/shift character.   Sigh....)

Perhaps if we were going to do it all over, we might have only
supported ASCII, or ISO Latin-1, and not used Unicode at all.  But
then I'm sure Valve or Android mobile handset manufacturers would be
unhappy that this might not be good enough for some country that they
want to sell into, like, say, Japan or more generally, any country
beyond US and Europe.

What we probably could do is to create our own table that didn't
support all Unicode scripts, but only the ones which are required by
Valve and Android.  But that would require someone willing to do this
work on a volunteer basis, or confinuce some company to pay to do this
work.  We could probably reduce the kernel size by doing this, and it
would probably make the code more maintainable.  I'm just not sure
anyone thinks its worthwhile to invest more into it.  In fact, I'm a
bit surprised Kent decided he wanted to add this feature into bcachefs.

Sometimes, partitioning a feature which is only needed for backwards
compatibiltiy with is in fact the right approach.  And throwing good
money after bad is rarely worth it.

Cheers,

						- Ted