Я читав щось подібне до цього вчора щодо OSX, і це стиснення файлової системи - в основному відповідь обертається навколо того, що ви хочете стиснути - у цьому прикладі він говорить про дані "FAT"; структури файлів, властивості, метадані та ін., які, зберігаючи разом, можна стиснути, щоб заощадити простір та прочитати на процесор швидше, ніж шукати голову всюди, щоб знайти дані для кожного файлу ...
Але стиснення стосується не лише економії місця на диску. Це також класичний приклад торгівлі циклами процесора для зменшення затримки вводу / виводу та пропускної здатності. За останні кілька десятиліть продуктивність процесора покращилась (а обчислювальні ресурси були багатішими - про це пізніше) набагато швидше, ніж продуктивність диска зросла. Сучасний час пошуку жорсткого диска і затримки обертання все ще вимірюються в мілісекундах. За одну мілісекунд процесор 2 ГГц проходить через два мільйони циклів. І тоді, звичайно, ще потрібно врахувати фактичний час передачі даних.
Зрозуміло, кілька рівнів кешування в ОС та апаратних засобах потужно працюють, щоб приховати ці затримки. Але ці біти повинні зійти з диска в якийсь момент, щоб заповнити ці кеші. Стиснення означає, що потрібно перенести менше бітів. Зважаючи на майже комічну перенасиченість ресурсів процесора на сучасному багатоядерному Mac при нормальному використанні, загальний час, необхідний для перенесення стисненого корисного навантаження з диска та використання ЦП для декомпресії його вмісту в пам'ять, як правило, буде набагато менше часу знадобиться передача даних у нестисненому вигляді.
Це пояснює потенційні переваги продуктивності передачі меншої кількості даних, але використання розширених атрибутів для зберігання вмісту файлів може насправді зробити все швидше. Це все стосується локалізації даних.
Якщо є одна річ, яка сповільнює жорсткий диск більше, ніж передача великої кількості даних, це переміщення головки з однієї частини диска в іншу. Кожен хід означає час, коли голова почне рухатися, потім зупиниться, потім переконайтесь, що вона правильно розміщена над потрібним місцем, а потім дочекайтеся, коли крутячий диск помістить потрібні біти під неї. Це все реальні, фізичні, рухомі частини, і дивно, що вони танцюють так само швидко і ефективно, як і вони, але фізика має свої межі. Ці рухи - справжні вбивці для ротаційного зберігання, як жорсткі диски.
Формат тома HFS + зберігає всю свою інформацію про файли - метадані - у двох основних місцях на диску: Каталог-файл, який зберігає дати файлів, дозволи, права власності та безліч інших речей, а також файл атрибутів, який зберігає "названі вилки" . "
Розширені атрибути в HFS + реалізуються як названі вилки у файлі атрибутів. Але на відміну від вилок ресурсів, які можуть бути дуже великими (до максимального розміру файлу, що підтримується файловою системою), розширені атрибути в HFS + зберігаються "вбудованим" у файлі атрибутів. На практиці це означає обмеження близько 128 байт на атрибут. Але це також означає, що головка диска не потребує поїздки в іншу частину диска, щоб отримати фактичні дані.
Як ви можете собі уявити, до блоків дисків, що складають файли каталогу та атрибутів, часто доступний, і тому швидше за все десь знаходиться в кеші. Все це має змогу зробити повне збереження файлу, включаючи як його метадані у своїх даних, у файлах каталогу та атрибутів, структурованих B-деревом, загальну виграш у продуктивності. Навіть восьмибайтовий корисний набір балонів на 25 байт не викликає занепокоєння, якщо він все-таки менший за розмір блоку виділення для нормального зберігання даних і доки він все вміщується у вузолі дерева B у файлі атрибутів, ОС все одно має читати в повному обсязі.
Є й інші вагомі внески до зменшення сліду диска Snow Leopard (наприклад, видалення зайвих локалізацій та файлів "designable.nib"), але стиснення HFS + є на сьогодні найбільш технічно цікавим.
