Я читал о заметке о патче Linux 5.2, выпущенной в прошлом году, и заметил, что они началидополнительная поддержка регистронезависимых имен в файловой системе ext4.
Так... мне интересно, почему опция без учета регистра (включая casefold и нормализацию) была нужна в ядре. Я мог бы узнатьдругая статьянаписанный Крисманом, который написал код ядра для поддержки файловой системы с привязкой к регистру, но case-insensitive file system allows us to resolve important bottlenecks for applications being ported from other operating systemsон не доходит до моего сердца, и я не могу понять, как процесс нормализации и привязки к регистру позволяет нам оптимизировать наше дисковое хранилище.
Я очень признателен за вашу помощь!
решение1
Файловая система, нечувствительная к регистру, позволяет нам устранять важные узкие места для приложений, переносимых из других операционных систем.
не доходит до моего сердца, и я не могу понять, как процесс нормализации и фолдинга позволяет нам оптимизировать наше дисковое хранилище.
Вино, 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 просто ускорил все, переместив процесс в пространство kenel†. Он все еще должен был проходить по файловой системе (и, таким образом, был ограничен вводом-выводом), вводил условия гонки и был принципиально ненадежен. Вот почему Google финансировал† разработку собственной нечувствительности к регистру для каждого каталога в F2FS и с тех пор объявил устаревшимSDCardFS.
В прошлом было несколько попыток включить поиск без учета регистра через VFS. Последняя попытка в 2018 году позволила смонтироватьнечувствительный к регистру просмотр файловой системы. Тед Цо специально упомянул проблемы с wrapfs для добавления этой функциональности, так как это было бы по крайней мере быстрее и (я считаю) без условий гонки. Однако это все еще было необоснованно (запрос README.TXTмог возвращать readme.txtили README.txt). Это было отклонено в пользу простого добавления поддержки для каталогов для нечувствительности к регистру и вряд ли когда-либо попадет в VFS††.
Более того, пользователи ожидают отсутствия чувствительности к регистру, поэтому любая ориентированная на потребителя операционная система должна ее обеспечивать. Unix не могла поддерживать ее изначально, поскольку Unicode не существовал, а строки были просто мешками байтов. Существует множество обоснованных критических замечаний по поводу того, как обрабатывалось сворачивание регистрав прошлом, но Unicode предоставляетнеизменный функция складывания корпусаэто работает для всех, кромеодин регион(тюркский, и даже тогда это всего лишь два кодовых пункта). Ифайловая система b-дерево— единственное разумное место для реализации такого поведения.
†АФАИКТ
††Я написал по электронной почте Крисману, автору как поиска без учета регистра на основе VFS, так и поддержки учета регистра на уровне каталогов в EXT4 и F2FS.
решение2
В других операционных системах файловая система нечувствительна к регистру.
Например: MacOS допускает регистронезависимость (по умолчанию) или регистрозависимость. Adobe Photoshop и Adobe Lightroom плохо работают с файловой системой, чувствительной к регистру. Это означает, что в программах Adobe, вероятно, есть жестко закодированные пути, записанные по-разному (возможно, «Документы» и «Документы» в разных библиотеках, или просто иногда применяются какие-то фильтры (например, строчные буквы и удаление пробелов, которые могут отличаться от пути к данным). Никого это не волновало, потому что это просто работало.
Итак, если вы хотите перенести программу, созданную для какой-то распространенной проприетарной операционной системы нашей эпохи, вам следует либо исправить все пути, чтобы всегда иметь единообразное использование регистров имен файлов, либо предпочесть файловую систему, которая будет обрабатывать это за вас.
Adobe не смогла сделать это для MacOS, поэтому ожидайте, что для других поставщиков все будет гораздо сложнее (и дороже). Смотретьhttps://helpx.adobe.com/creative-suite/kb/error-case-sensitive-drives-supported.html
решение3
Я не знаю ни одной причины для использования чувствительной к регистру файловой системы: единственное, что она делает, это то, что она полностью сбивает с толку пользователя. Разработчики Microsoft понимали это с самого начала и не стали заморачиваться с неработающей концепцией. Теперь, тридцать лет спустя, некоторые разработчики Linux поняли, что нечувствительность к регистру безопаснее и логичнее, и наконец-то реализовали ее.
Почему самые первые файловые системы Unix были чувствительны к регистру? Возможно, это связано с тем, что процессору проще с ними работать. Вам не нужны дополнительные функции, которые потребляют циклы процессора, чтобы проверить, существует ли файл с похожим именем, хотя и с другим регистром (также есть алфавиты, отличные от латинского/английского, где реализация независимости от регистра нетривиальна). В настоящее время, с современными сверхбыстрыми процессорами, это не такая уж и большая проблема.