Линус Торвальдс и файловая система OS X

Еще в 2008 году Линус Торвальдс в своем интервью сказал, что «в некотором смысле OS X на самом деле хуже, чем Windows для программирования. Их файловая система полная и полная чушь, что страшно». Я искал более подробную информацию о том, почему он так относится к файловой системе OS X (по-видимому, HFS +), но я не смог ничего найти.

Линусу определенно не нравится базовая модель файловой системы Unix, и я сомневаюсь, что он ненавидит HFS + за то, что он не учитывает регистр. И несмотря на то, как провокационно его комментарий сформулирован, я сомневаюсь, что он совершенно бесполезен. Поскольку комментарий был в контексте программирования для OS X, я подозреваю, что его мнение, возможно, основывалось на производительности, надежности, интерфейсе операционной системы или чем-то подобном. Кто-нибудь знает, какие жалобы Линус эпохи 2008 года мог иметь с HFS + эпохи 2008 года?

Стенограмма сессии «Q & A» , в котором Линус сделал комментарий доступен, но он , кажется , не было предложено разработать. Я не уверен, был ли более глубокий анализ его мнения о HFS + записан где-то еще.

Для чьего-либо анализа этого вопроса вы можете посмотреть обзоры Джона Сиракузы по Mac OS X. В частности, тот, что для Mac OS X Lion, в котором есть раздел под названием « Что не так с HFS +» . Я думаю, что наиболее важный момент - это (выделение мое):

Параллелизм, метаданные, записанные в правильном порядке байтов, точность данных с точностью до секунды, поддержка больших объемов томов и поддержка разреженных файлов - все это общие характеристики файловых систем Unix. Mac OS X, конечно, построен на основе Unix. Когда HFS + был перенесен с классической Mac OS на Mac OS X, его необходимо было расширить для поддержки некоторого минимального набора функций, которые ожидаются от файловых систем Unix .

Некоторые из этих функций легко подходили, но другие было очень трудно добавить в файловую систему без нарушения обратной совместимости. Один особенно страшный пример - использование жестких ссылок в HFS +. Чтобы отслеживать жесткие ссылки, HFS + создает отдельный файл для каждой жесткой ссылки в скрытом каталоге на корневом уровне тома. С самого начала скрытые каталоги выглядят довольно жутко, но настоящий страх возникает, когда вы вспоминаете, что Time Machine реализована с использованием жестких ссылок, чтобы избежать ненужного дублирования данных.

Важным моментом здесь является то, что Mac OS X использует файловую систему, которая даже не была разработана для системы Unix, она была разработана для классической Mac OS и исправлена ​​для реализации функций Mac OS X 10.0 при сохранении обратной совместимости. Впоследствии Apple реализовала дополнительные функции, которые она теперь имеет в Mac OS X 10.7 (ведение журнала, метаданные, события файловой системы ...), используя тот же подход исправления, а не подход «с нуля». Я не уверен, как объяснить это нетехнически, но вы могли бы сказать, что все эти дополнительные функции опираются на классическую основу Mac OS, которая никогда не была разработана для их поддержки. Это означает, что решение не так хорошо, как могло бы быть. Пример, который Siracusa продолжает обсуждать, заключается в том, что решение, которое Apple пришлось использовать для жестких ссылок, работая в рамках ограничений HFS +, слишком чувствительно к аппаратному отказу, что усугубляется тем фактом, что HFS + также никогда не был предназначен для работы с данными. целостность. Конечно, поддержание совместимости с классической Mac OS было желательным ограничением в Mac OS X 10.0, но в Mac OS X 10.7 его больше нет.

Хотя я не эксперт по операционной системе, и я только начал использовать OSX после выхода из Windows, я считаю себя PowerUser в Windows и достаточно компетентным в Linux. Исходя из этого, я был удивлен, что в довольно современной ОС, такой как OSX, файловая система имеет такие особенности, как способ «именования файлов».

Я понимаю, что проблемы Linus с HFS + проистекают из той же точки: из того, что я обнаружил, исследуя проблему, HFS + сохраняет имена файлов с использованием Unicode, но когда файл использует "расширенные" или символы NON-ASCII (например, é, í, ó, ú, ñ с испанского или что-то вроде ü на немецком языке), для которого Unicode предоставляет 2 способа кодирования имени, OSX молча «нормализует» кодировку во время хранения ... Не реальная проблема, когда файл был создан и использован в OSX, но когда вы делитесь информацией с пользователями других ОС, тот факт, что имя файла меняется, вызывает все виды странного поведения ...

Показательный пример: я отслеживал свои «артефакты» (файлы, документы и т. Д.) В Subversion последние 8 лет. При переходе на Mac у меня появился клиент SVN для Mac, и после выполнения Checkout моих соответствующих каталогов я обнаружил, что все файлы с акцентами, по-видимому, отсутствуют, и новый файл с тем же именем отображается как не версионный. Если углубиться в это, проблема заключается в том, что файл IN в файловой системе кодируется яблоком, а данные в хранилище используют другую (совершенно правильную и законную) кодировку Unicode ...

Я думаю, это грубое искажение моих данных. Apple понимает оба формата кодировки имени файла (при доступе к общему ресурсу в Windows или при использовании USB-накопителя из Windows отображаются правильные имена файлов и т. Д.), Но во время создания файла было решено, что «он знает лучше», и просто переименовывает файлы. ..

Опять же, не то, что большинство пользователей заметят - пока они не сделают копию файла или не переименуют его и не вернут туда, где находился исходный файл, а в итоге получат два файла, которые, очевидно, совпадают !!!)

Джон Сиракуза и Дэн Бенджамин обсуждают некоторые недостатки HFS + в Hypercritical # 56 .

Они решают проблему повреждения данных в HFS + и учитывают некоторые особенности ZFS.