Лінус Торвальдс та файлова система 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, яка ніколи не була розроблена для їх підтримки. Це означає, що рішення не так добре, як могло б бути. Приклад, який Сіракуза продовжує обговорювати, - це те, що рішення, яке Apple довелося використовувати для жорстких посилань, працюючи в межах обмежень HFS +, є надто чутливим до апаратних збоїв, що посилюється тим, що HFS + також ніколи не був розроблений, щоб стосуватися даних цілісність. Звичайно, підтримка сумісності з класичною Mac OS була бажаним обмеженням у Mac OS X 10.0, але насправді це вже не в Mac OS X 10.7.

Хоча я не фахівець з операційної системи, і я тільки почав використовувати OSX після приходу з Windows, я вважаю себе PowerUser в Windows і досить компетентний в Linux. Виходячи з цього фону, я здивувався, що в досить сучасній ОС, на зразок OSX, у файловій системі є химерності, такі як спосіб "ігнорувати імена файлів".

Я розумію, що проблеми Лінуса з 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.