為什麼需要 ext4 中不區分大小寫的選項？
我正在閱讀去年發布的 Linux 5.2 更新檔說明，我注意到他們開始對ext4 文件系統中不區分大小寫的名稱提供可選支持。
所以……我想知道的是核心中需要不區分大小寫選項（包括大小寫和規範化）的原因。我可以找到Krisman 寫的另一篇文章
case-insensitive file system allows us to resolve important bottlenecks for applications being ported from other operating systems，他編寫了支持 case-folding 文件系統的核心程式碼，但沒有觸及我的心，我無法理解規範化和 casefolding 的過程如何讓我們優化我們的磁碟儲存。我非常感謝您的幫助！
> > 不區分大小寫的文件系統使我們能夠解決從其他作業系統移植的應用程序的重要瓶頸 > > >
沒有觸及我的心，我無法理解規範化和案例折疊的過程如何讓我們優化我們的磁碟儲存。
Wine、 Samba 和 Android必須提供不區分大小寫的文件系統語義。如果底層文件系統區分大小寫，則每次區分大小寫的查找失敗時，Wine 等人。必須掃描每個目錄以證明沒有不區分大小寫的匹配項（例如，如果查找失敗，您必須執行完整的目錄列表以及,和 中的所有文件和所有目錄的
/foo/bar/readme.txt大小寫比較）。foo/bar/*``foo/*``/*這樣做有幾個問題：
- 對於深度嵌套的路徑（可以生成數百個 FS 呼叫）或包含數万個文件的目錄（即通過 SMB 儲存增量備份），它會變得非常慢。
- 這些檢查引入了競爭條件。
- 從根本上講，這是不合理的：如果兩者都
readme.txt存在README.txt，但應用程序要求README.TXT，則返回的文件是未定義的。Android 甚至使用 FUSE/wrapfs 和核心SDCardFS來模擬不區分大小寫。然而，SDCardFS 只是通過將程序移動到 kenel 空間使一切變得更快†。它仍然必須遍歷文件系統（因此受到 IO 限制），引入了競爭條件，並且從根本上說是不健全的。因此，為什麼 Google 資助† 在 F2FS 中開發本機每個目錄不區分大小寫，並且此後棄用了 SDCardFS。
過去曾多次嘗試通過 VFS 啟用不區分大小寫的查找。2018 年的最新嘗試允許安裝不區分大小寫的文件系統視圖。Ted Tso 特別提到了 wrapfs 添加此功能的問題，因為它至少會更快並且（我相信）沒有競爭條件。但是，它仍然不健全（請求
README.TXT可以返回readme.txt或README.txt）。這被拒絕了，只支持為不區分大小寫添加每個目錄的支持，並且不太可能將其納入 VFS††。此外，使用者期望不區分大小寫，因此任何面向消費者的作業系統都必須提供它。Unix 本身無法支持它，因為 Unicode 不存在並且字元串只是字節袋。對於過去如何處理大小寫折疊有很多有效的批評，但 Unicode 提供了一個不可變的 大小寫折疊功能，該功能適用於除單個語言環境（突厥語，即使這樣也只是兩個程式碼點）之外的所有地方。文件系統 b-tree是實現此行為的唯一合理位置。
† AFAICT
††我給 Krisman 發送了電子郵件，他是 EXT4 和 F2FS 上基於 VFS 的不區分大小寫查找和每個目錄不區分大小寫支持的作者。