EXT4 Getting Faster Case-Insensitive Performance

[carewolf]

Another guy seeing thigs that are only in his own mind.

This is a filesystem feature that is needed by one of the possible usecases. Like Samba shares, or Wine application folders.

It's not on by default and it's specifically designed to be enabled on a folder basis.

It isn't needed. It could be extra API.

Ironically Windows went the other way. They have have Linux APIs that makes it possible to store files that otherwise would name clash with normal Windows APIs.. NTFS have always been able to handle both, it is just different APIs.

[starshipeleven]

It isn't needed. It could be extra API.

Afaik there is no real requirement for an extra API (beyond internet trolls posing as software developers). This is just a quick workaround for some problematic applications, that's it.

[xfcemint]

Still true, even if it's "more efficient" for your own usecase it's still not as efficient as case-sensitive and applications that don't need that (the vast majority) are getting hit for no reason.

Case-sensitive comparison is equally fast as case insensitive (more precisely, the difference is negligible when used in file-system operations.
But you should have known that. Only amateurs don't know this. So, perhaps, you just don't know what you are talking about here.

Only applications actually having issues with that are Samba and Wine stuff. But there is no reason to do that with a new application.

If some applications are having issues with it today, than it is reasonable to expect that there might be future applications having the same problem.
Wine is not old. It is a modern app. The problem is that there is no other way to do it, so Wine will suffer as long as this functionality is missing from the kernel.

Maybe you are suggesting to just delete Wine and Samba? Or an even better solution: don't use Linux at all, and your problems are solved!

You aren't making much sense then, is your application requiring the user to set this filesystem/folder option on all folders he keeps his documents and stuff just because your application needs to find his stuff?

Oh, you don't even understand how it's supposed to work? Do you always take strong positions about things you don't understand?

I implied that if all current applications can do it you can do it too for your specific usecase and it will be fine.

It is not fine (to emulate case-insensitive file-open by retrieving a list of all files in a directory) because:
- it is slower
- it requires extra code and testing
- requires code duplication
- requires extra error checking, memory allocation and other things which experts know very well about, but amateur's don't
- requires extra case handling (when two synonymous files exist in the same dir).
- etc, etc...

In short, it is not fine because it is not an elegant solution. An elegant solution is to provide this functionality on the kernel level.

[oiaohm]

Case-sensitive comparison is equally fast as case insensitive (more precisely, the difference is negligible when used in file-system operations.

https://lwn.net/ml/linux-fsdevel/201...collabora.com/
No case-sensitive comparison at file system driver level is in fact slower than case-sensitive you have a longer code path. If what you are doing is like a Linux kernel build having the file system folder where it is as case insensitive does hurt by taking longer.

It is not fine (to emulate case-insensitive file-open by retrieving a list of all files in a directory) because:
- it is slower
- it requires extra code and testing

This is true at kernel level as well. Just not as much as processing full list in userspace.

- requires code duplication

Kernel level avoid code duplication this is the advantage of doing in kernel space is you don't have to duplicate up the hash table and this table can be cached between runs.

- requires extra error checking, memory allocation and other things which experts know very well about, but amateur's don't
- requires extra case handling (when two synonymous files exist in the same dir).

These is true at kernel level as well. Casefold at kernel level requires extra memory allocation and extra checking.
Bugs in file system means two synonymous files may exist so true at kernel level.

- etc, etc...

You did not mention these. I would suspect most of them effect kernel level as well. There is very little difference in issues between implementing in kernel space and implementing in userspace. Duplicate processing issue/Duplicated code is the fairly much the total performance hit difference between the user space and kernel implementation. All the other performance/memory hits from being case insensitive other than the Duplicate processing issue/Duplicated code stay the same when you move the processing of case insensitive from user space to kernel space.

In short, it is not fine because it is not an elegant solution. An elegant solution is to provide this functionality on the kernel level.

Yes it might be more elegant for the kernel to provide case insensitive over userspace. But case insensitive is not a free no matter where you implement it. Cheapest in performance cost is always case sensitive.

The advantage of implementing case insensitive in kernel space is avoiding some duplication and race condition problems. The avoid some duplication increases performance but it does not change the fact that case insensitive processing is still slower than case sensitive processing even when in kernel space.

Case insensitive search is always a longer code path than a case sensitive one. The reason why Linux kernel developers resisted adding case insensitive support for so long is the fact it adds extra code into file system layer to be debugged and harms performance. Of course those emulating case insensitive in user-space being wine and samba were being hit worse.