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

28

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

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

Kenster
источник
2
Он был известен тем, что имел действительно сильные мнения о некоторых вещах, например, когда он выступал с докладом о git @ google, он потратил большую часть разговора, разбивая другие системы. Поэтому я бы сказал, что у него, вероятно, есть причина верить в то, что он думает, но он также очень преувеличенный человек, хотя он и гений. youtube.com/watch?v=4XpnKHJAok8
El Developer
3
Если вы не получили здесь ответ на этот вопрос, на который вы надеялись, вы можете также подумать о поиске (и, возможно, также и об этом) в Unix & Linux или Super User . (Так много сайтов , доступных в настоящее время иногда трудно понять , что место , чтобы задать вопрос По крайней мере , имхо :)..
иррациональное John
Я склонен биться с HFS + больше, чем любая другая файловая система, с которой я обычно сталкиваюсь. Сейчас в большинстве систем я не чувствую, что обычно замечаю или беспокоюсь о том, какую файловую систему она использует, но HFS + всегда что-то придумывает. Как и сегодня, я обнаружил, что меня обескураживает отсутствие субсекундного разрешения для модов. Также было время, когда я обнаружил две строки кода на C, которые могли вызвать тупиковую ситуацию в файловой системе, в значительной степени разрушив всю машину. Это даже не было исправлено на 10,5. Не уверен насчет более свежих версий.
Iguananaut

Ответы:

21

Стенограмма сессии «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 его больше нет.

Rinzwind
источник
1
Отличная ссылка; это охватывает много важных вещей. Отсутствие редкой поддержки файлов - довольно чокнутый. Linux ext2 создавал разреженные файлы даже при простом распределении на основе блоков, как в HFS +. Я думаю, что он слишком много делает для хранения метаданных в формате с прямым порядком байтов. bswapИнструкция x86 очень быстрая. Это делает код больше и уродливее, но поддержание совместимости на диске является большой проблемой. Linux XFS по-прежнему хранит все метаданные с прямым порядком байтов (кроме native-endian в журнале) из-за его происхождения в SGI на процессорах MIPS. Это не идеальная ситуация, но XFS не сдерживается этим.
Питер Кордес
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 отображаются правильные имена файлов и т. Д.), Но во время создания файла было решено, что «он знает лучше», и просто переименовывает файлы. ..

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

JJarava
источник
1
Это только один момент, и реальная проблема заключается в том, что разные ОС просто по-разному нормализуют строки, и кросс-платформенные приложения не справляются с этим. Не нормализуя названия, вероятно , будет хуже (вы можете иметь два разных файла с именами , которые нормализуют к одной и той же строке, на OS X).
Blaisorblade
4

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

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

badams
источник
9
Можно ли как-то представить резюме их обсуждения в своем ответе? Аудиопоток (на данный момент в нашей современной технологии) недоступен для поиска и очень длинный. Не говоря уже о том, что он находится на другом сайте, поэтому на него может ссылаться гниль. Это было бы намного лучшим ответом, если бы он содержал определенные детали об их обсуждении.
Ян С.
1
Разговор о файловой системе начинается через 23 минуты.
neoneye
1
Большая часть информации, доступной в подкасте, также может быть найдена в статье Ars Technica Джона Сиракузы (один из двух мужчин в подкасте.)
TML