为什么 ext4 中需要不区分大小写的选项？

Question

我正在阅读去年发布的 Linux 5.2 补丁说明，我注意到他们开始对ext4 文件系统中不区分大小写的名称提供可选支持。

所以...我想知道内核中需要不区分大小写的选项（包括大小写和标准化）的原因。我可以找到Krisman 写的另一篇文章，他编写了支持大小写折叠文件系统的内核代码，但case-insensitive file system allows us to resolve important bottlenecks for applications being ported from other operating systems没有触及我的内心，我无法理解规范化和大小写折叠的过程如何让我们优化磁盘存储。

我非常感谢您的帮助！

Answer 1

\n

\n

不区分大小写的文件系统使我们能够解决从其他操作系统移植应用程序的重要瓶颈

\n

\n

没有打动我的心，我无法理解规范化和案例折叠的过程如何让我们优化磁盘存储。

\n

\n

Wine、Samba 和 Android必须提供不区分大小写的文件系统语义。如果底层文件系统区分大小写，则每次区分大小写的查找都会失败，Wine 等人。必须扫描每个目录以证明不存在不区分大小写的匹配项（例如，如果查找/foo/bar/readme.txt失败，则必须对 、 和 中的所有文件和所有目录执行完整的目录列表和大小写比较foo/bar/*）。foo/*/*

\n

这有几个问题：

\n

\n
• 对于深度嵌套的路径（可以生成数百个 FS 调用）或包含数万个文件的目录（即通过 SMB 存储增量备份），它可能会变得非常慢。
\n
• 这些检查引入了竞争条件。
\n
• 这从根本上来说是不合理的：如果 和 都readme.txt存在README.txt，但应用程序要求README.TXT，则返回哪个文件是未定义的。
\n

\n

Android 甚至使用 FUSE/wrapfs 以及内核中的SDCardFS来模拟不区分大小写。然而，SDCardFS 只是通过将进程移至内核空间\xe2\x80\xa0 来使一切变得更快。它仍然必须遍历文件系统（因此受到 IO 限制），引入了竞争条件，并且从根本上来说是不健全的。因此，为什么 Google 资助 \xe2\x80\xa0 在 F2FS 中开发本机每个目录不区分大小写的功能，并从此弃用了SDCardFS。

\n

过去曾多次尝试通过 VFS 启用不区分大小写的查找。2018 年的最新尝试允许安装文件系统的不区分大小写的视图。Ted Tso 特别提到了添加此功能时使用的 Wrapfs 的问题，因为它至少会更快并且（我相信）没有竞争条件。然而，它仍然不健全（请求README.TXT可以返回readme.txt或README.txt）。这被拒绝了，只支持添加每个目录对大小写不敏感的支持，并且不太可能将其放入 VFS\xe2\x80\xa0\xe2\x80\xa0 中。

\n

此外，用户期望不区分大小写，因此任何面向消费者的操作系统都必须提供它。Unix 本身无法支持它，因为 Unicode 不存在并且字符串只是字节包。对于过去处理大小写折叠的方式有很多有效的批评，但 Unicode 提供了一个不可变的 大小写折叠函数，该函数适用于除单个语言环境（突厥语，甚至只有两个代码点）之外的所有语言环境。文件系统 B 树是实现此行为的唯一合理位置。

\n

\xe2\x80\xa0 AFAICT
\n\xe2\x80\xa0\xe2\x80\xa0我给 Krisman 发了电子邮件，他是 EXT4 和 F2FS 上基于 VFS 的不区分大小写查找和每个目录不区分大小写支持的作者。

\n