EXT4 Case-Insensitive Directories/File-Name Lookups Coming With Linux 5.2

[wizard69]

Why would anyone want this?

Thanks for posting my question, the case insensitivity feature is beyond explanation. Frankly it strikes me as fat impacting code reliability for no reason. As for UTF8 that should of happened a long time ago.

[skeevy420]

Every time the ram consumption exceeds, my operating system crashes becoming unusable, because of overcharged Hard Drive . Which is the cause?

Because you've posted this in multiple threads now:

Care to list your system specs? It's extremely doubtful that stuff like duplicated kernel timers and case insensitivity are the cause of your slowdowns.

I only ask because I haven't really had any day to day, simple activity overloads since my Athlon 64 x2 with 2gb DDR2 or Q6600 with 3GB DDR2 days. Once I put 8GB in that Q6600 12 years ago, that has been a thing of the past outside of the HDD slowdowns and "the web browser has yet another memory eating bug".

Personally, I consider a Core2+ CPU with 4 threads and 8GB to be the minimum one should use for a Gnome or KDE desktop. Yeah, my KDE desktop uses less than 600mb on boot...but not once I start doing stuff. I should add that one has to change the default distribution values to make that work, like maybe needing to enable zswap, limit the size of /tmp, ZFS ARC limiting, lower the swap value; things like that. Sometimes I think the Linux devs forget about the average day-to-day computers when I see things like systemd ganking half the ram for /tmp.

The reason I say all that is that I'm at 4.9GB usage right now with Firefox with 5 tabs open (one is STiscovery on pause), PulseEffects, SC-Controller, Steam, & Lutris and, if this were an 8GB system and I a noob, I'd be using swap space since Manjaro/systemd has /tmp setup to use half of the system's available ram by default. ZFS on my system can use up to another half of the remaining ram. Someone with an 8GB system using systemd only has 4GB available to the OS. Add in ZFS and your down to 2GB available until ZFS frees up the ARC which will then cause drive slowdowns...can't win for losing there.

All that said, I do have 48GB of ram, 16GB allocated to the OS, so there is a really good chance that Firefox, other programs, the kernel in general, all aren't being as conservative on my system as they might on a lower ram system. Every tweak I mentioned above is in use on my system outside of limiting /tmp.

[wizard69]

Case sensitivity in a file system has always seemed to me the like proper thing to do. The times when I would re-format an Apple computer, I would always select case-sensitive and wonder why that was even a choice. But apparently I had never taken into consideration that there are some people who don't know how to manage their files, and would quickly end up with "My File" and "My file" in the same directory.

A person that can’t manage his files is a user space problem and doesn’t justify case insensitivity in any file system. I know what you mean here as I’ve had software once that did the unexpected with name case. Still that doesn’t justify an OS file system change.

This really seems like like an EXT4 update split between good and evil. Case insensitivity being a real evil and UTF8 support being the way forward.

[skeevy420]

Thanks for posting my question, the case insensitivity feature is beyond explanation. Frankly it strikes me as fat impacting code reliability for no reason. As for UTF8 that should of happened a long time ago.

Game modding and Wine. Seems that all that we at Phoronix need it for...but as someone who as considered installing Windows in a VM just to deal with extracting game mods, damn I'd have loved this back when I played Morrowind...

[KellyClowers]

Burn it with fire

[KellyClowers]

Every time the ram consumption exceeds, my operating system crashes becoming unusable, because of overcharged Hard Drive . Which is the cause?

This isn't a support thread, dingus

[mercster]

There is a whole world of uses of computers that many of you have not encountered, use cases you do not have the imagination to think of. It has nothing to do with FAT, or "stupid users" who are too lazy to maintain their case-sensitive filenames.

[F.Ultra]

Thanks for posting my question, the case insensitivity feature is beyond explanation. Frankly it strikes me as fat impacting code reliability for no reason. As for UTF8 that should of happened a long time ago.

The only justification that I could find was Krismans (he is the kernel dev that have created this patchset) presentation from the Linux Plumbers Conf: https://linuxplumbersconf.org/event/...ve-lookups.pdf

Why an encoding-aware FS?
●Traditional UNIX-like approach: Opaque byte sequences.
●Because the other kids are doing it.
●Real world use cases:–Porting from the Windows world.–Android exposes case-insensitive tree.–Better support for exported filesystems.
●User space hacks are slow and racy.

●File uniqueness: Doesn’t translate well to real-world languages:[krisman@dilma]$ ls -li toráx
15631222 -rw-r--r-- 1 root root 0 Nov 1 01:47 coração
15631218 -rw-r--r-- 1 root root 0 Nov 1 01:46 coração
15631217 -rw-r--r-- 1 root root 0 Nov 1 01:46 coração
15631215 -rw-r--r-- 1 root root 0 Nov 1 01:46 coração
●Lack of normalization is confusing for non-english speakers.
●What is the definition of Case without an encoding?

[lkundrak]

Given that it is being implemented for EXT4, what is the practical use of this feature? I could perfectly understand if they did this for the NTFS driver (compatibility for shared drives), but EXT4?

Android SD card emulation (that aims to mimic FAT fs)

[discordian]

I get storing the encoding for some filesystems, although with ext4 (and other fs exclusive to *nix) this could have just been fixed to UTF8 with a small revision.

What I wont ever get is what purpose languages and case-insensivity have lost in the kernel.

Have problems with different UTF8 encodings denoting the same human interpretation -> do normalization in userspace
Have problems with case -> do normalization in userspace (to either lower or upper case)
Want to still save some CamelCase or special kind encoding for display to the user -> save that in an extent (or whatever metadata extension is available)

Apply that to all filenames (like interposing the libc open function) and you don't end up with any kind of race, quick byte-compare lookups and alot less baggage in the kernel.