Ich habe die Patchnote zu Linux 5.2 gelesen, die letztes Jahr veröffentlicht wurde. Dabei ist mir aufgefallen, dass sie angefangen haben,optionale Unterstützung für Groß- und Kleinschreibung ignorierende Namen im Ext4-Dateisystem.
Also... ich frage mich, warum die Option „case-insensitive“ (einschließlich Casefold und Normalisierung) im Kernel benötigt wurde. Ich könnte herausfinden,Ein weiterer Artikelgeschrieben von Krisman, der den Kernelcode zur Unterstützung des Case-Folding-Dateisystems geschrieben hat, case-insensitive file system allows us to resolve important bottlenecks for applications being ported from other operating systemserreicht mich aber nicht und ich kann nicht verstehen, wie der Prozess der Normalisierung und Case-Folding es uns ermöglicht, unseren Festplattenspeicher zu optimieren.
Ich bin sehr dankbar für Ihre Hilfe!
Antwort1
Das Case-Insensitive-Dateisystem ermöglicht es uns, wichtige Engpässe für Anwendungen zu beseitigen, die von anderen Betriebssystemen portiert werden.
erreicht mein Herz nicht und ich kann nicht verstehen, wie der Prozess der Normalisierung und Casefolding es uns ermöglicht, unseren Festplattenspeicher zu optimieren.
Wein, Samba und Androidhabenum eine Dateisystemsemantik ohne Berücksichtigung der Groß- und Kleinschreibung bereitzustellen. Wenn das zugrunde liegende Dateisystem zwischen Groß- und Kleinschreibung unterscheidet, müssen Wine et al. jedes Mal, wenn eine Suche mit Berücksichtigung der Groß- und Kleinschreibung fehlschlägt, jedes Verzeichnis scannen, um zu beweisen, dass es keine Übereinstimmungen ohne Berücksichtigung der Groß- und Kleinschreibung gibt (wenn die Suche beispielsweise /foo/bar/readme.txtfehlschlägt, müssen Sie eine vollständige Verzeichnisliste und einen Vergleich aller Dateien in foo/bar/*und aller Verzeichnisse in foo/*, und , mit Berücksichtigung der Groß- und Kleinschreibung durchführen /*).
Dies bringt einige Probleme mit sich:
- Bei tief verschachtelten Pfaden (dieHunderte von FS-Anrufen) oder Verzeichnisse mit Zehntausenden von Dateien (dhSpeichern inkrementeller Backups über SMB).
- Diese Prüfungen führen zu Race Conditions.
- Das ist grundsätzlich nicht stichhaltig: Wenn sowohl als
readme.txtauchREADME.txtvorhanden sind, eine Anwendung jedoch nach anfordertREADME.TXT, ist undefiniert, welche Datei zurückgegeben wird.
Android ging so weit, die Case-Insensitivität mit FUSE/wrapfs zu emulieren und dann den In-KernelSDCardFS. Allerdings hat SDCardFS alles nur schneller gemacht, indem es den Prozess in den Kenel-Bereich verschoben hat. Es musste immer noch das Dateisystem durchlaufen (und war daher IO-gebunden), führte zu Race Conditions und war grundsätzlich nicht zuverlässig. Deshalb hat Google die Entwicklung der nativen Groß-/Kleinschreibungsunabhängigkeit pro Verzeichnis in F2FS finanziert und ist seitdem veraltet.SDCardFS.
In der Vergangenheit gab es mehrere Versuche, Groß- und Kleinschreibungs-unabhängige Suchvorgänge über VFS zu ermöglichen. Der jüngste Versuch im Jahr 2018 ermöglichte die Bereitstellung einesGroß-/Kleinschreibung ignorierende Ansicht des Dateisystems. Ted Tso verwies beim Hinzufügen dieser Funktionalität speziell auf die Probleme mit Wrapfs, da es zumindest schneller und (glaube ich) frei von Race Conditions wäre. Es war jedoch immer noch nicht stichhaltig (Anfragen konnten oder README.TXTzurückgeben ). Dies wurde zugunsten der bloßen Hinzufügung von Unterstützung für die Groß-/Kleinschreibung pro Verzeichnis abgelehnt und wird es wahrscheinlich nie in VFS†† schaffen.readme.txtREADME.txt
Darüber hinaus erwarten Benutzer, dass die Groß- und Kleinschreibung ignoriert wird, sodass jedes verbraucherorientierte Betriebssystem dies unterstützen muss. Unix konnte dies nicht nativ unterstützen, da Unicode nicht existierte und Zeichenfolgen nur Byte-Bags waren. Es gibt viele berechtigte Kritikpunkte an der Art und Weise, wie die Groß- und Kleinschreibung gehandhabt wurde.in der Vergangenheit, aber Unicode bietet eineunveränderlich Case-Fold-Funktiondas funktioniert für alle, aberein einzelnes Gebietsschema(Turkisch, und selbst dann sind es nur zwei Codepunkte). Und dieDateisystem B-Baumist der einzig sinnvolle Ort, um dieses Verhalten zu implementieren.
†Soweit ich weiß
††Ich habe Krisman eine E-Mail geschickt, dem Autor der VFS-basierten Case-Insensitive-Lookups und der Case-Insensitive-Unterstützung pro Verzeichnis auf EXT4 und F2FS.
Antwort2
Bei anderen Betriebssystemen wird in Dateisystemen nicht zwischen Groß- und Kleinschreibung unterschieden.
Ein Beispiel: MacOS erlaubt Groß- und Kleinschreibung (als Standard) oder Groß- und Kleinschreibung. Adobe Photoshop und Adobe Lightroom funktionieren nicht gut mit Groß- und Kleinschreibung-sensitiven Dateisystemen. Das bedeutet, dass es in Adobe-Programmen wahrscheinlich fest codierte Pfade gibt, die auf unterschiedliche Weise geschrieben werden (vielleicht „Dokumente“ und „Dokumente“ in den verschiedenen Bibliotheken, oder dass manchmal einfach Filter angewendet werden (z. B. Kleinschreibung und Entfernen von Leerzeichen, die vom Pfad der Daten abweichen können). Niemand hat sich darum gekümmert, weil es einfach funktioniert hat.
Wenn Sie also jetzt ein Programm portieren möchten, das für ein gängiges proprietäres Betriebssystem unserer Zeit erstellt wurde, sollten Sie entweder alle Pfade korrigieren, damit die Groß- und Kleinschreibung von Dateinamen immer einheitlich verwendet wird, oder Sie bevorzugen ein Dateisystem, das dies für Sie übernimmt.
Adobe konnte dies für MacOS nicht umsetzen, daher ist zu erwarten, dass es für andere Anbieter viel schwieriger (und kostspieliger) wird. Siehehttps://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html
Antwort3
Ich kenne keinen einzigen Grund für ein Case-Sensitive-FS: es verwirrt den Benutzer nur völlig. Die Microsoft-Entwickler haben es von Anfang an verstanden und sich nicht mit einem fehlerhaften Konzept herumgeschlagen. Jetzt, dreißig Jahre später, haben einige Linux-Entwickler erkannt, dass die Case-Insensitivität sicherer und logischer ist, und haben sie schließlich implementiert.
Warum waren die allerersten Unix-Dateisysteme case-sensitiv? Das könnte daran liegen, dass die Arbeit mit ihnen für die CPU einfacher ist. Sie benötigen keine zusätzlichen Funktionen, die CPU-Zyklen verbrauchen, um zu überprüfen, ob eine Datei mit einem ähnlichen Namen bereits existiert, wenn auch mit anderer Groß- und Kleinschreibung (außerdem gibt es andere Alphabete als Latein/Englisch, bei denen die Implementierung der Case-Insensitivität nicht trivial ist). Heutzutage ist das mit modernen, superschnellen CPUs keine große Sache.