Defrag or not defrag? Или зачем нам фрагменты наших файлов?
Defrag or not defrag, that is the question
Грустный Гамлет, сидя перед Маком
Часто встречалось мне на просторах интернета мнение, что дефрагментация маковской HFS+ (иерархическая файловая система, разработанная компанией Apple), бесполезна, ненужна, и просто вредна. Что ж давайте разберёмся вместе так ли это. Заодно посмотрим, что нам предлагают разработчики программных продуктов.
В общем о дефрагментации HFS+ на Mac OS X.
Надо ли? Зачем? И главное - как?
1. Немного истории.
HFS + Иерархическая файловая система +(Hierarchical File System plus), известная также как Mac OS Extended была представлена в виде бета-версии 19 января 1998 года, а в окончательном релизе появилась на Mac OS X 10.2.2 11 ноября 2002 года. В Mac OS X 10.3 HFS + с журналированием стала файловой системой по умолчанию, в ней появилась поддержка Unicode 3.2
С 10.4 Apple добавили поддержку Inline Attribute Data records, что было частью Mac OS X реализации HFS Plus по крайней мере с 10.0, но всегда помечались как «зарезервировано для использования в будущем».
До выпуска Mac OS X Server 10.4 HFS Plus поддерживал только стандартные UNIX "разрешения файлов" ("file system permissions"), однако в 10.4 появилась поддержка безопасности файлов на основе списка управления доступом (ACL), которая обеспечивает более мощные механизмы для определения "разрешений файлов", и стала полностью совместима с моделями "разрешений файлов" на других платформах, таких как Microsoft Windows XP и Windows Server 2003, и современных реализаций UNIX/Linux.
В Mac OS X Snow Leopard 10.6 было добавлено сжатие файловой системы.
В Mac OS X Lion 10.7 появилось также и "прозрачное" (на лету) сжатие файлов.
В HFS файлы хранятся в формате битовой маски, директории и некотроые расширенные атрибуты в структуре B-Tree, что обеспечивает эффективный поиск и позиционирование с минимальной вычислительной нагрузкой.
2. Еще немного истории.
В нашем небольшом экскурсе в прошлое файловых систем мы пропустим первые и ушедшие в прошлое файловые системы такие как CP/M и FAT, настоящая история развития файловых систем для ПК начинается с разработки OS/2 и её файловой системы HPFS (High Performance File System). Разработку начинали IBM и Microsoft в 1985 году, но позже Microsoft покинула проект и "силами" IBM OS/2 сошёл на-нет. Если честно - жаль! Замечательная была ОС для своего времени, но Microsoft не нужен был конкурент, и воспользовавшись совместными наработками в ходе проекта, Бил Гейтс успешно задавил, набирающую обороты ОС (ох как часто он проделывал такое, но вот он оскал рыночной борьбы)!
Именно на OS/2 в 1989 году появилась прогрессивная для своего времени HPFS, где структура файловой системы базировалась на списках B-tree, что позволило снять ограничения присущие FAT и значительно повысить эффективность ОС. Так например в HPFS в отличии от FAT директории также хранились в B-tree, что снимало ограничения на размер корневого каталога (в FAT директориями являлись списки, внутри которых и располагались файлы) и длину имени файла, а также позволило уменьшить время поиска, и повысить эффективность размещения данных на диске. Многое из этого возьмут в Microsoft для своей NTFS - файловой системы, разработанной для Windows NT.
В середине 1993 года выходит ОС от Microsoft - Windows NT 3.1 с поддержкой NTFS v1.0 - это начало нового направления Microsoft, в конце концов приведших к Windows Server и Windows 7 (8), а также начало конца OS/2.
Последний официальный релиз NTFS - v5.1.
В NTFS также используются структуры B-tree, для хранения указателей на директории и содержимое их, но структура директорий храниться в специально отведённой области - MFT, а информация о bad block в файле $badclus. Вместе с тем, что NTFS поддерживает все механизмы защиты файлов на основе ACL и file permissions, а также жесткие и символические ссылки (hard links, symbolic links) - NTFS имеет ряд нововведений, не присущих другим ФС - такие как Single Instance Storage (SIS), Distributed Link Tracking (DLT), Hierarchical Storage Management (HSM) и т.д..
Всё - больше не будем погружаться в историю!
Браво всем, кто дочитал до этого места!
3. История О. (История???? Опять???!!!!)
Еще чуть о заблуждениях и предпосылках этих заблуждений.
С появлением NTFS Microsoft провозгласила : "Теперь нет нужды в дефрагментации диска! Мы создали совершенную файловою систему и совершенную ОС! Наша система базируется на принципе "Lazy Write" (ленивая запись), то есть в процессе работы за компьютером данные пишутся на первое подходящие по размеру окно (место) на диске и с очень большой вероятностью, когда вы вновь будете работать в то же приложении - то головки вашего "винчестера" при чтении данных окажутся почти в том месте, где они и были записаны этим приложением!"
Ну ведь логично!? Логично! И вроде так и должно быть в природе, но ....
1993 год - размер жесткого диска в 120 мегабайт - это уже супер! А файлы? Файлы редко занимали размер больше полутора мегабайта. Даже фотки были в разрешении SVGA - 800x600 - и это было здорово (во всяком случае нам так казалось ;)). Так, что при написании текстов и таблиц - этого вполне хватало почти за глаза, не забудьте, что появился и "защищённый режим", позволивший адресовать всю оперативную память, а не 640 килобайт как это было до этого! В любом случае - казалось, что наконец -то достигнут баланс между железом и софтом - и он идеален!
"Аппетит приходит во время еды." - любил повторять народную мудрость мой дед.
Так и случилось!
Появились мощные процессоры - появились ОС, способные переварить эту мощь - как следствие, появились инструменты, позволяющие программировать (кодировать) более "мощные" приложения - этим приложениям уже стало не хватать "простора" - появились более мощные процессоры - ВСЁ "замкнутый цикл" см. начало предложения....
К чему это я? А к тому, что к 2000 году Microsoft забывает о "Lazy Write" и официально включает в ОС утилиту дефрагментации, а в FAQ, насчёт повышения производительности советует проводить дефрагментацию периодически.
Не бойтесь, я не забыл, что пишу для счастливых владельцев Мак!
Всю эту "главку" я написал для того, что бы было понятно и для "неофитов" и для опытных "маководов", а пример с Microsoft - так ведь только они и сознались, что в современном компьютерном мире - как ни крути, но "желаемое (планируемое) не всегда соответствует реальности.
4. Реалии и мифы.
В одном из мак - сообществ, человек задал вопрос - "Надо ли дефрагментировать диск на Маке?"
Меня поразили ответы "Яблочных Гуру"...
- Нет не надо, Мак сам дефрагментирует, то что необходимо с помощью Daily, Weekly, Monthly scripts.
- Файловая система Mac OS X - не подвержена фрагментации.
- Дефрагментация приводит к потери производительности.
Друзья мои, услышите такие советы - больше не спрашивайте этих "гуру"!
Про Daily, Weekly, Monthly scripts я уже писал, и разве что забыл упомянуть, что Weekly и Monthly еще и сжимают логи в 10.7...
Если вы используете HDD - то просто представьте себе, как можно реализовать "безфрагментный" алгоритм записи - стирания!
SSD - это другое! И если вы дочитали и до сих пор! Спасибо вам и обещаю вернуться к этому вопросу - там тоже не всё так однозначно, как может показаться....
Правильный "дефрагментатор" - разве, что "замедлит" загрузку вашего Мака только после дефрагментации, ну это связанно с перестройкой кэшей и т.п.
5. Выбираем правильный дефрагментатор.
А вот это - в следующем посте.
А пока, бесперебойной работы вашему Маку!
Ну и пишите.... если что.