GNU/Linux >> Linux の 問題 >  >> Linux

ext4 で大文字と小文字を区別しないオプションが必要だったのはなぜですか?

<ブロック引用><ブロック引用>

大文字と小文字を区別しないファイル システムにより、他のオペレーティング システムから移植されたアプリケーションの重要なボトルネックを解決できます

心に届かず、正規化とケースフォールディングのプロセスによってディスク ストレージを最適化する方法が理解できません。

Wine、Samba、Android にはある 大文字と小文字を区別しないファイルシステムのセマンティクスを提供します。基礎となるファイルシステムが大文字と小文字を区別する場合、大文字と小文字を区別するルックアップが失敗するたびに、Wine et al。大文字と小文字を区別しない一致がないことを証明するために、各ディレクトリをスキャンする必要があります (例:/foo/bar/readme.txt を検索する場合) 失敗した場合は、foo/bar/* 内のすべてのファイルの完全なディレクトリ リストと大文字と小文字の比較を実行する必要があります。 foo/* 内のすべてのディレクトリ 、および /* ).

これにはいくつかの問題があります:

  • 深くネストされたパス (数百の FS 呼び出しを生成する可能性がある) または数万のファイルを含むディレクトリ (つまり、SMB 経由で増分バックアップを保存する) では、非常に遅くなる可能性があります。
  • これらのチェックにより、競合状態が発生します。
  • 根本的に不健全です:両方が readme.txt の場合 および README.txt 存在しますが、アプリケーションが README.TXT を要求します 、返されるファイルは未定義です。

Android は、FUSE/wrapfs を使用して大文字と小文字を区別せず、次にカーネル内の SDCardFS をエミュレートするところまで行きました。ただし、SDCardFS は、プロセスをケネル空間に移動することですべてを高速化しました†。それでもファイルシステムを歩き回る必要があり (したがって IO バウンド)、競合状態が発生し、根本的に健全ではありませんでした。したがって、Google が F2FS でディレクトリごとの大文字と小文字を区別しないネイティブの開発に資金を提供†し、その後 SDCardFS を非推奨にした理由です。

過去に、VFS を介して大文字と小文字を区別しないルックアップを有効にする試みが複数ありました。 2018 年の最新の試みでは、ファイルシステムの大文字と小文字を区別しないビューをマウントできました。 Ted Tso は特に、この機能を追加するための wrapfs の問題を挙げました。これは、少なくとも高速で (私は信じています) 競合状態がないためです。しかし、それはまだ不健全でした (README.TXT を要求しています) readme.txt を返す可能性があります または README.txt )。これは、大文字と小文字を区別しないディレクトリごとのサポートを追加することを支持して却下され、VFS†† に組み込まれる可能性は低いです。

さらに、ユーザーは大文字と小文字を区別しないことを期待しているため、消費者向けのオペレーティング システムはそれを提供する必要があります。 Unicode が存在せず、文字列が単なるバイトの袋だったため、Unix はそれをネイティブにサポートできませんでした。大文字と小文字の折り畳みが過去にどのように処理されたかについては、多くの正当な批判がありますが、Unicode は、1 つのロケール (トルコ語、および 2 つのコードポイントのみ) を除くすべてのロケールで機能する不変の大文字と小文字の折り畳み関数を提供します。ファイルシステムの B ツリーは、この動作を実装する唯一の適切な場所です。

AFAICT
††VFS ベースの大文字と小文字を区別しないルックアップと、EXT4 および F2FS でのディレクトリごとの大文字と小文字を区別しないサポートの両方の作成者である Krisman にメールしました。


他のオペレーティング システムでは、大文字と小文字を区別しないファイル システムがあります。

例:MacOS は、大文字と小文字を区別しない (デフォルトとして) または大文字と小文字を区別することを許可します。 Adobe Photoshop および Adob​​e Lightroom は、大文字と小文字を区別するファイル システムではうまく機能しません。これは、Adobe プログラム内に、さまざまな方法で記述されたハードコードされたパスが存在する可能性があることを意味します (さまざまなライブラリの "ドキュメント" と "ドキュメント" など)。データのパス). それはちょうど動作するので、誰も気にしませんでした.

したがって、私たちの時代の一般的なプロプライエタリ オペレーティング システム用に作成されたプログラムを移植する場合は、すべてのパスを修正して、ファイル名の大文字と小文字を常に一貫して使用するか、これらを処理するファイル システムを使用することをお勧めします。

Adobe は MacOS でそれを行うことができなかったので、他のベンダーにとってははるかに困難 (かつ費用がかかる) と予想されます。 https://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html を参照してください


Linux
  1. Linux での mkfs.ext4 コマンドの例

  2. Ansible:ext4 ファイルシステムのサイズを変更することは可能ですか?

  3. Linux:大文字と小文字を区別しないファイルシステム

  1. rsync が遅いのはなぜですか?

  2. ディスクをマウントできません (VFS:ext4 ファイルシステムが見つかりません)

  3. ext4 と組み合わせた透過的な圧縮ファイルシステム

  1. Linuxを使用してヨガスタジオを管理する理由

  2. MacからLinuxに切り替えた理由

  3. Ext4ファイルシステムのオフセットを見つける方法は?