Case-insensitive ext4

Posted Mar 27, 2019 19:25 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: Case-insensitive ext4 by Karellen
Parent article: Case-insensitive ext4

If you don't add case-insensitive version of open() and friends then every open() call will have to scan the whole directory first. This adds up quickly for Samba and other file-server use-cases.

Case-insensitive ext4

Posted Mar 27, 2019 20:02 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link] (15 responses)

It could as well maintain a userspace dictionary mapping normalized/ lowercased names to their actual names (which could be maintained incrementally based on filesystem change notifications).

Case-insensitive ext4

Posted Mar 27, 2019 20:05 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

Linux has no filesystem notification mechanisms that have required consistency and performance for a fileserver use-case.

Case-insensitive ext4

Posted Mar 27, 2019 21:17 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link] (8 responses)

There is no such thing as "a fileserver use case". Samba exists and has existed (and been used) for a while, hence, there are obviously "file server use cases" where the existing mechanisms perform well enough.

Case-insensitive ext4

Posted Mar 27, 2019 21:26 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Samba exists, but it does case insensitivity in a very expensive way. There are other use-cases as well, like mounting FAT filesystems.

I've seen this firsthand - I'm using a Linux server for TimeMachine backups for Mac OS X. TimeMachine is braindead - it creates hundreds of thousands files in the same directory. With the default settings Samba slowed down to a crawl.

Fortunately, TimeMachine doesn't care about file name cases. So by following steps from here: https://wiki.samba.org/index.php/Performance_Tuning I was able to speed up backups by something like 10x. This is not insignificant and it would be nice for Linux to handle similar use-cases natively.

Case-insensitive ext4

Posted Mar 28, 2019 0:50 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (6 responses)

> there are obviously "file server use cases" where the existing mechanisms perform well enough.

Have you talked to Samba developers and asked them if they are happy with the current performance or would like to see better support from the kernel? If you haven't I would encourage you to do that or talk to enterprises supporting Samba or even large customers. I think you will find that perspectives useful to add to your opinions.

Case-insensitive ext4

Posted Mar 28, 2019 16:10 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (5 responses)

Someone claimed that Samba opening a file residing on a case-sensitive filesystem would require a pre-open, linear directory traversal. As I pointed out, this isn't true, at least not on Linux: It would be possible to use an incrementally maintained, userspace translation cache instead, however, unless I again have to use Samba for something in a resource-constrained environment, I'm not going to implement that and in the unlikely case that this would happen, I'd certainly not go through the rather pointless hassle of trying to contribute a non-trivial change to an open sausage project, as I have neither the time to do this nor the social skills and pedigree to do so successfully.

Case-insensitive ext4

Posted Mar 28, 2019 18:36 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> As I pointed out, this isn't true, at least not on Linux: It would be possible to use an incrementally maintained
Nope. There is no way to maintain this cache with any sort of consistency guarantees. Linux filesystem change notifications are not up to it.

Case-insensitive ext4

Posted Mar 29, 2019 3:03 UTC (Fri) by pabs (subscriber, #43278) [Link] (2 responses)

What are they missing now that recent Linux versions offer rename notifications and other directory change notifications?

Case-insensitive ext4

Posted Mar 29, 2019 4:21 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

inotify is not recursive. It's also best-effort and its notifications are asynchronous.

fanotify is better, but it also can drop events from time to time under high load.

Case-insensitive ext4

Posted Oct 4, 2023 18:51 UTC (Wed) by calumapplepie (guest, #143655) [Link]

You get an event when the queue overflows. If you clear the cache on receiving such an event, you can provide consistency guarantees, at the cost of bad performance while the cache is rebuilt. Since the queue is pretty big, overflows shouldn't happen too much.

Case-insensitive ext4

Posted Mar 29, 2019 22:55 UTC (Fri) by jra (subscriber, #55261) [Link]

We already have an incrementally maintained, userspace translation cache in Samba. It catches the simple cases where we've seen a filename before - we cache it.

Unfortunately it isn't enough. Cache misses are the problem. If the SMB client sends a filename "foo" and it isn't in the directory, we don't know if it doesn't exist, or exists under another case (e.g. as "Foo"). In that case we need to scan the directory. This gets really expensive, really quickly.

We don't negatively cache as we're often used to export filesystems that local processes are also modifying.

I've been wanting a case-insensitive filesystem lookup option in Linux for a long time (I think ZFS and XFS already have it, however flawed).

Case-insensitive ext4

Posted Mar 28, 2019 7:28 UTC (Thu) by patrakov (subscriber, #97174) [Link] (1 responses)

Wouldn't it simplify things if SAMBA stopped any attempts to export an existing directory tree? I.e. mandate that the only way to make a new file exported is to copy it in via the SMB protocol, quite possibly from localhost. Keep filenames opaque, keep files in a clearly-private area, teach users not to mess with them (like they don't directly mess with MySQL files). Keep whatever attributes Windows needs in some sort of a database.

Case-insensitive ext4

Posted Mar 28, 2019 7:35 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

This is doable and is fairly easy, given that Samba has a well-defined pluggable VFS layer.

But this will break a ton of other software that wants to directly modify the disk files. It will also mean that Linux's VFS is inadequate for a fairly common use-case.

Case-insensitive ext4

Posted Mar 27, 2019 20:17 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (2 responses)

Ideally this would be some kind of LRU cache which would have some flag to say "this is a one-off open, don't cache" to avoid the inotify (or whatever) mechanism. Plus, I'm sure folks would love having the C library run a thread in the background to listen for its notifications taking locks on this cache whenever something happens. Yeah, I don't see any race conditions, unpredicitable latency issues, or TOCTOU/cache coherency issues here at all.

Sorry for the snark, it's not in response to your comment in particular, but my mind coming up with all the Pandora's boxes this is threatening to open.

Case-insensitive ext4

Posted Mar 27, 2019 21:11 UTC (Wed) by rweikusat2 (subscriber, #117920) [Link] (1 responses)

There's no point in special-casing "one-off opens" unless this demonstrably solves a problem. As then kernel open has to scan the directory, anyway, you'll end up with the exact same kind of TOCTOU races. This is a problem which can't really be solved. As to your other objections: These is a generic list of programming errors, some of them attributable to the idea with "a background thread".

It's possible to implement case-insensitive open in user space without doing a second linear search through a directory for every open.

Case-insensitive ext4

Posted Mar 27, 2019 21:19 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

As I understand, the kernel will keep track of canonicalized names in file cache, so it won't have to do a search.

There's also the problem of making sure that no duplicate files exist.

Case-insensitive ext4

Posted Mar 29, 2019 9:16 UTC (Fri) by Karellen (subscriber, #67644) [Link] (2 responses)

Why?

How is a call to open() getting the filename to open? Either it's going to from an existing directory scan, in which case the capitalisation/normal form should already be correct, or it's going to be because a user has selected a file - in which case the shell/picker/whatever should be able to do that work already?

Where would calls to open() be getting these correctly named but incorrectly capitalised/normalised filenames from?

Case-insensitive ext4

Posted Mar 29, 2019 9:20 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> How is a call to open() getting the filename to open? Either it's going to from an existing directory scan, in which case the capitalisation/normal form should already be correct, or it's going to be because a user has selected a file - in which case the shell/picker/whatever should be able to do that work already?
You have an SMB request to open a file, with a file name. There's nothing else.

You can try a happy case and just attempt an open() with the provided name. If it fails, you need to scan the directory to find a matching file with a different case.

And you can't really cache the negative result, patterns like "if !exists(fname) {creat(fname);}" are exceedingly common.

Case-insensitive ext4

Posted Apr 4, 2019 17:09 UTC (Thu) by Wol (subscriber, #4433) [Link]

> Where would calls to open() be getting these correctly named but incorrectly capitalised/normalised filenames from?

The user, maybe?

What about the use case where I type in a name in a picker, and it displays a bunch of matches?

Or what about the case where I typed in the name on the command line? Some of us still use a command line, you know ...

Cheers,
Wol