Дефрагментация ntfs
Достаточно интересный момент – это фрагментация и дефрагментация NTFS. Дело в том, что ситуация, сложившаяся с этими двумя понятиями в настоящий момент, никак не может быть названа удовлетворительной. В самом начале утверждалось, что NTFS не подвержена фрагментации файлов. Это оказалось не совсем так, и утверждение сменили - NTFS препятствует фрагментации. Оказалось, что и это не совсем так. То есть она, конечно, препятствует, но толк от этого близок к нулю... Сейчас уже понятно, что NTFS - система, которая как никакая другая предрасположена к фрагментации, что бы ни утверждалось официально. Единственное что - логически она не очень от этого страдает. Все внутренние структуры построены таким образом, что фрагментация не мешает быстро находить фрагменты данных. Но от физического последствия фрагментации - лишних движений головок - она, конечно, не спасает. Мы же попробуем выяснить, почему так происходит. Как известно, система сильнее всего фрагментирует файлы когда свободное место кончается, когда приходится использовать мелкие дырки, оставшиеся от других файлов. Тут возникает первое свойство NTFS, которое прямо способствует серьезной фрагментации. Диск NTFS поделен на две зоны. В начале диска идет MFT зона - зона, куда растет MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных в эту зону невозможна. Это сделано для того, чтобы не фрагментировался хотя бы MFT. Но когда весь остальной диск заполняется - зона сокращается ровно в два раза. И так далее. Таким образом, мы имеем не один заход окончания диска, а несколько. В результате если NTFS работает при диске, заполненном примерно на 90% - фрагментация растет как бешенная. Попутное неприятное следствие состоит в том, что диск, заполненный более чем на 88%, дефрагментировать почти невозможно - даже API дефрагментации не может перемещать данные в MFT зону. Может оказаться так, что у нас не будет свободного места для маневра. Но и это еще не все. NTFS фрагментируется даже в том случае, если свободное место далеко от истощения. Этому способствует странный алгоритм нахождения свободного места для записи файлов - второе серьезное упущение. Алгоритм действий при любой записи такой: берется какой-то определенный объем диска и заполняется файлом до упора. Причем по очень интересному алгоритму: сначала заполняются большие дырки, потом маленькие. Т.е. типичное распределение фрагментов файла по размеру на фрагментированной NTFS выглядит так (размеры фрагментов):
16-16-16-16-16 – (скачок назад) – 15-15-15-15 – (скачок назад) …
Так процесс идет до самых мелких дырок в 1 кластер, несмотря на то, что на диске наверняка есть и гораздо более большие куски свободного места. А если еще вспомнить сжатые файлы - при активной перезаписи больших объемов сжатой информации на NTFS образуется гигантское количество "дырок" из-за перераспределения на диске сжатых объемов - если какой-либо участок файла стал сжиматься лучше или хуже, его приходится либо изымать из непрерывной цепочки и размещать в другом месте, либо стягивать в объеме, оставляя за собой дырку. Вот и получается в итоге, что NTFS не препятствует фрагментации, а наоборот, с «радостью» фрагментирует даже то, что можно было не фрагментировать.
В NT существует стандартное API дефрагментации. Обладающее интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16 кластеров, причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Из этого следует:
В дырку свободного места менее 16 кластеров нельзя ничего переместить (кроме сжатых файлов, но это неинтересные в данный момент тонкости).
Файл, будучи перемещенный в другое место, оставляет после себя (на новом месте) "временно занятое место", дополняющее его по размеру до кратности 16 кластерам.
При попытке как-то неправильно ("не кратно 16") переместить файл, результат часто непредсказуем. Что-то округляется, что-то просто не перемещается… Тем не менее, всё место действия щедро рассыпается "временно занятым местом" ("временно занятое место" служит для облегчения восстановления системы в случае аппаратного сбоя и освобождается через некоторое время, обычно где-то пол минуты).
Процесс дефрагментации состоит из следующих фаз:
Вынимание файлов из MFT зоны. Не специально – просто вернуть их туда обратно не представляется возможным. Безобидная фаза, и даже в чем то полезная.
Дефрагментация файлов. Безусловно, полезный процесс, несколько, правда, осложняемый ограничениями кратности перемещений - файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму.
Дефрагментация MFT, файла виртуальной памяти (pagefile.sys) и каталогов. Возможна через API только в Windows2000, иначе - при перезагрузке, отдельным процессом.
Складывание файлов ближе к началу - так называемая дефрагментация свободного места. Вот об этом страшном процессе подробнее.
Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 19. Кладем следующий - после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку размером менее 16 кластеров, которую потом невозможно заполнить через API дефрагментации. В результате, до оптимизации картина свободного места выглядела так: много дырок примерно одинакового размера. После оптимизации - одна дыра в конце диска, и много маленьких (менее 16 кластеров) дырок в заполненном файлами участке.
RAID
RAID (Redundant Array of Inexpensive Disks) - избыточный массив недорогих дисков. Технология, заключающаяся в одновременном использовании нескольких дисковых устройств для обеспечения характеристик надежности или скорости, отсутствующих у накопителей в отдельности. Windows NT поддерживает на программном уровне три уровня RAID:
RAID 0 (параллельные диски)
Простейшая реализация RAID 0 из двух, например, дисков - указание на то, что каждый первый сектор тома (или любой другой объем информации) расположен на физическом диске A, а каждый второй - на диске B. Такая жесткая стратегия дает возможность избежать каких-либо дополнительных структур для хранения информации о том, где находятся какие данные. Скорость чтения, как и записи равны и зависят от числа дисков:
Быстродействие операции по работе со случайно расположенными данными подчиняются следующей схеме: всё зависит от вероятности того, что диск, на который мы хотим записать очередную порцию информации, свободен и готов мгновенно выполнить наш запрос. Например, RAID 0 из двух дисков: при осуществлении операции одним из дисков и поступлении дополнительной команды на работу с дисковой системой вероятность того, что для выполнения команды нам придется тревожить свободный в данный момент диск составляет 50% - это соответствует общему увеличению производительности случайных операций в полтора раза. Если же используется, к примеру, массив из десяти дисков, то вероятность какой-либо операции попасть на уже занятый накопитель составляет всего 10% - то есть производительность повышается в девять раз. Любителям строгой теории вероятности хочу заметить, что при таких подсчетах не учитываются некоторые факторы реальной работы систем, но цифры, тем не менее, имеют именно такой порядок.
Последовательные операции - чтение или запись последовательных участков - проходят практически всегда в n раз быстрее, чем на отдельном физическом диске, где n - число дисков в наборе. Это происходит потому, что вероятность в следующей операции попасть на свободный диск составляет 100% - ведь операции осуществляются последовательными блоками, которые равномерно раскидываются по дискам.
Таким образом, RAID 0 существенно повышает быстродействие линейных операций, а с увеличением числа дисков, входящих в набор, существенно повышается скорость работы и со случайными данными. Для эффективной работы с дисковой системой в режиме RAID 0 просто необходим многозадачный режим работы контроллера, а желательно даже разных контроллеров, обеспечивающих доступ к разным дискам. Обязательным условием такой работы на интерфейсах IDE являются Bus-Mastering драйвера. Windows 2000 имеет встроенные драйвера, автоматически включающие этот режим для всех распространенных IDE контроллеров. Надежность RAID 0 низка, так как выход из строя хотя бы одного диска является фатальным сбоем. В целом, вероятность сбоя системы только повышается. Чем больше дисков используется, тем больше вероятность того, что хотя бы один из них выйдет из строя и, соответственно, что потеряется какая-то часть тома.
RAID 1 (зеркальные диски)
Самый простой способ обеспечения безопасности данных - создать копию двух дисков. Запись осуществляется на оба диска сразу, что приводит к замедлению этого процесса, тогда как чтение - с того диска, который в данный момент свободен - если, конечно, система способна эффективно осуществить такое чтение (необходимо наличие Bus-Mastering). Реализованный в NT алгоритм, к сожалению, не совсем оптимален и приводит к гораздо более скромному увеличению быстродействия чтения. Некоторая сложность работы RAID 1 в программном режиме заключается в том, что часто система не может быть до конца уверена в идентичности данных двух дисков. Операция сверки двух физических дисков после серьезного сбоя может затянутся на часы и быть очень некстати, поэтому использовать программный RAID 1 следует очень осмотрительно. Если вы решаетесь на увеличение дисковых массивов в несколько раз только ради надежности, возможно, вам стоит приобрести аппаратный RAID контроллер, который, к тому же, обеспечит замену вышедших из строя дисков прямо на ходу и будет следить за синхронностью данных сам.
RAID 1 достаточно надежен, так как даже полный отказ одного из дисков не приводит к потере данных, так как диски полностью зеркальны.
RAID 5 (параллельные диски с четностью)
Данная стратегия представляется в настоящее время наиболее удачной и эффективной схемой работы RAID, состоящих из трех и более дисков. Информация дополняется так называемыми данными четности (parity), которые размещаются на другом физическом диске, нежели реальные данные, контролируемые этой информацией. Суть четности состоит в следующем. Допустим у нас есть 5 бит (1,0,1,1,0). Мы формируем еще один бит, шестой бит – бит четности. Если число едениц в предыдущих пяти бит четно, то он будет равен 1, если нечетно – то 0. Получаем новую последовательность (1,0,1,1,0,<0>). Теперь предположим, что нанесен урон (1,0,Х,1,0,<0>). Следуя правилу о четности, мы легко можем восстановить потерянный бит по биту четности. Наш получившийся набор из шести бит (5 бит данных и 1 бит четности) избыточен и может грамотно скорректировать потерю любого из своих шести бит. Операции четности могут осуществляться не только с битами, но и с любыми объемами данных, что применяется в простейших алгоритмах восстановления данных. Итак, вернемся к сути RAID 5.
Рис.2.4. Дисковый массив
На данном рисунке изображен массив из пяти дисков. Видно, что каждый диск хранит (условно) 4 части реальных данных и одну часть четности. Блок четности - скажем, 0 parity - способен восстановить потерю одного из фрагментов - любого, но одного - среди A0, B0, C0 и D0. Все вместе они, в свою очередь, способны восстановить блок 0 parity. Из изображенной структуры RAID видно, что данные, необходимые для полного восстановления всего столбика - то есть информации любого диска в случае сбоя - находятся на других дисках. В этом и заключается восстановление - при записи данных на любой из дисков обновляется также блок четности другого диска, соответствующего текущему блоку (например, при записи в A2 обновляется еще и блок 2 parity). Чтение данных с исправного диска происходит без использования блоков четности, т.е. почти в том же режиме, в каком работает RAID 0. Быстродействие RAID 5 в том виде, в каком это реализовано в NT, даже немного выше, чем у RAID0. Единственная накладка - в случае сбоя производительность массива снижается в огромное количество раз, так как при невозможности напрямую считать, например, D4, нужно будет восстанавливать данные этого блока с использованием всех других дисков одновременно - в нашем случае это будут блоки 4 parity, B4, C4 и E4. Как видно, выход из строя одного из дисков RAID 5 является хоть и не фатальной, но резко аварийной ситуацией - хотя бы из соображений быстродействия чтения с массива. Нетрудно догадаться также, откуда исходит требования как минимум трех дисков - в случае двух накопителей RAID 5 просто вырождается в RAID 1, так как единственный способ создать информацию четности списка из одного элемента - это тем или иным образом дублировать этот элемент.
RAID также не является панацеей от абсолютно всех бед. На ненадежном (некорректном) компьютере RAID грохнуть почти так же легко, как и однодисковую систему. RAID совершенно не спасет в следующих случаях:
Корректная запись некорректных данных, а также запись данных мимо ожидаемой области. К этому приводят, как и ранее, сбойная память, процессор, шлейф, контроллер, питание привода.
Если диск не способен сообщить об ошибке чтения.
RAID предназначен для минимизации ущерба всего в одном случае - при физическом отказе жесткого диска или, возможно, контроллера (в случае многоконтроллерного RAID). Отказы памяти, операционной системы, да и вообще всего остального RAID-ом не предусмотрены - точно так же, как и стратегией работы одиночной NTFS.
Любой сбой одного из дисков системы считается аварией, которую необходимо как можно быстрее ликвидировать. Особенно это относится к RAID 0 и RAID 5, штатная работа которых в условиях аварии одного из дисков практически невозможна.
Содержание отчета.
Отчет о работе должен содержать название лабораторной работы, фамилию и инициалы студента, номер группы; экспериментальные и теоретические данные, полученные в ходе выполнения задания; вывод по результатам выполнения работы; ответы на контрольные вопросы.
Задание.
Изучить материал, описанный в теоретической части, разобраться в нем. В отчет занести ответы на контрольные вопросы.
Контрольные вопросы.
Структура MFT.
Сжатие в NTFS.
Поиск файлов в NTFS.
Процесс дефрагментации в NTFS.
Типы RAID.
Лабораторная работа № 8
Работа с жесткими дисками в операционной системе “Linux”
Цель лабораторной работы.
Цель работы – Получение навыков работы с файлами и каталогами в операционной системе Linux.
Теоретическая часть[23].
Linux позволяет работать с великим множеством файловых систем, как локальных, так и сетевых. Однако у него есть и своя, родная, файловая система, носящая название ext2fs. Построена она предельно просто и логично: все в ней является файлами - данные, программы, каталоги, устройства (для примера - последовательные или параллельные порты). И потому файлы разделяются на типы:
обычные файлы;
каталоги;
файлы устройств;
ссылки.
Обычные файлы - это, во-первых, исполнимые двоичные файлы (типа файлов *.exe или *.com, но не привязанные к какому-либо расширению);во-вторых, ASCII-файлы, содержащие простой текст (сюда относится и подавляющее большинство системных конфигурационных файлов); в третьих, файлы данных, созданные какой-либо программой (текстовым процессором, графическим редактором или электронной таблицей, например) в собственном формате. Впрочем, все это пользователю DOS/Windows понятно.
Каталоги - это тоже файлы, содержащие информацию о каталогах: рекурсия - широко распространенный и любимый прием в мире Unix-систем. Каталоги объединяются в иерархическое дерево, начинающееся, как и положено, с корня (/ - root, корневой каталог) и растущее ввысь и вширь; любые накопители, как монтируемые при загрузке (жесткие диски, скажем, и их логические разделы), так и подключаемые в процессе работы (CD ROM, Zip, дискеты) - не более чем ветви дерева каталогов.
Файлы устройств - понятие для Windows-мигранта непривычное. Это нужно просто запомнить: все физические устройства, присутствующие в системы (порты ввода/вывода, накопители разного рода, звуковые устройства и прочие), с точки зрения ext2fs являются файлами. Устройства эти могут быть блочными (например, накопители) или символьными (порты ввода/вывода), но это - уже подробности.
Наконец, ссылки (links) - это некий аналог "ярлыков" в Windows или "теней" в OS/2. Ссылка может быть прямой, или жесткой (hardlink, или, часто, link просто) и символической (symlink). Первые могут указывать на любой файл в файловой системы, тогда как вторые обязаны находиться в одном дисковом разделе.
Файл, с точки зрения ext2fs состоит из двух частей. Первая - это нумерованная в шестнадцатеричном исчислении запись - inode (адекватного перевода мне обнаружить не удалось, иногда переводится как "узел"). В ней содержится информация о размере файла, его формате, правах доступа и т.д. Вторая часть - это имя файла, связанное с inode посредством прямой ссылки.Из этого следует:
Имя файла, включая и расширение, не играет в Linux такой сакральной роли, как в DOS/Windows. Если в последней сменить расширение в файле, скажем, *.psd на любое иное - считать его Photoshop уже не удастся. В Linux же в общем случае файлу данных любого типа может быть приписано любое расширение (или его может не быть вовсе): на понимание его породившей программой это никак не отразится. Более того, файл может иметь несколько расширений (то есть групп знаков, разделенных точками): типичный пример - архивный компрессированный файл *.tar.gz.
С одним и тем же inode может быть несколько сколько угодно ссылок, причем - не обязательно идентичных. То есть один и тот же физический файл как бы выступает под разными именами. Это играет важную роль при использовании библиотек, шрифтов и в ряде других случае.
В Linux файл (то есть inode) удаляется автоматически, когда становится недоступным для системы. Это происходит тогда, когда удалена последняя ссылка на него (а имя файла, удаляемое средствами командной строки или файлового менеджера - и есть такая ссылка) и закрыта последняя обращающаяся к нему программа.
Имеется аналог мусорной корзины Windows. Но это - просто отдельный каталог, куда помещаются файлы, полагаемые ненужными, чтобы глаза не мозолили. И откуда их можно даже не восстановить в смысле DOS, а просто скопировать обратно.
Максимальная длина имени файла (включая и любое количество "расширений") - 255 знаков. А максимально возможная длина пути - 4096, что практически можно считать бесконечным.
Структура каталогов в Linux жестко фиксирована, хотя в деталях и может разниться от дистрибутива к дистрибутиву. Обладая правами суперпользователя (администратор системы), ее можно изменить. Но - делать это ни в коем случае не следует - в результате система может просто утратить работоспособность.
Как правило, после инсталляции системы в корневом (/, root) каталоге присутствуют:
/bin - каталог для исполнимых (иначе называемых бинарными, binary) файлов общего назначения; здесь помещаются оболочки командной строки, общие команды управления файлами и их архивации, традиционные текстовые редакторы типа vi, и т.д.; именно каталог /bin в первую очередь просматривается на предмет поиска введенной с клавиатуры команды;
/boot, как явствует из названия, содержит файл образа ядра, с которого загружается система;
/dev - каталог для файлов устройств;
/etc - каталог для конфигурационных файлов общего пользования;
/home включает в себя домашние каталоги пользователей, со всеми их программами, личными конфигурационными файлами (имеющими в сеансе этого пользователя предпочтение перед общими файлами конфигурации) и данными;
/lib - каталог для общесистемных библиотек (аналогов DLL в Windows);
/mnt -каталог для монтирования сменных накопителей (вроде дискет) или временно подключаемых файловых систем (например, FAT-раздела диска);
/proc - виртуальная файловая система для чтения информации о процессах;
/root - аналог $home для суперпользователя;
/sbin содержит системные двоичные файлы, используемые для системного администрирования;
/tmp, понятно, включает в себя всякого рода временные файлы; как правило, этот автоматически очищается при перезагрузке или через некоторое время;
/usr - каталог для прикладных пользовательских программ со всеми их компонентами - исполнимыми, конфигурационными и разделяемыми файлами (/usr/bin, /usr/etc и /usr/share, соответственно), библиотеками (/usr/lib), документацией в различных форматах (/usr/doc, /usr/man) и т.д.; важный подкаталог /usr/local предназначен для программ, не входящих в дистрибутив стандартно - сюда по умолчанию инсталлируются компилируемые из исходных текстов приложения;
/var - каталог для варьирующих файлов, всякого рода системных журналов, почтовых и принтерных спуллингов и т.д.
Кроме того, в дереве могут присутствовать и некоторые другие каталоги, например, /opt - для опциональных компонентов, или /misc - для всего, что не подпадает под приведенные определения.
В общем, назначение каталогов и логика их организации понятна, если затратить некоторое время на изучение их содержимого. Трудности, скорее всего, могут возникнуть с каталогом /mount, поскольку ни DOS, ни Windows не имеют даже отдаленных аналогов этого понятия.
При инсталляции системы и создании дисковых разделов, необходимо задать для них точку монтирования. Скажем, для созданного нами раздела под пользовательские данные такая точка определялась как /home. Тем самым мы включили этот (или любой другой) дисковый раздел в структуру дерева каталогов Linux. Или, иными словами, смонтировали его в файловую систему Linux.
Разделы жесткого диска с файловой системой ext2fs обычно монтируются автоматически, при загрузке системы. Часто так же поступают и с FAT-разделами. А в Linux Mandrake (и некоторых других дистрибутивах) предусмотрено автоматическое монтирование и для сменных накопителей - дискет и CD ROM. Вот под них-то и отведен каталог /mnt.
Что и как монтируется - описано в конфигурационном файле /etc/fstab, в котором в каждой строке указывается (слева направо) имя устройства, точка его монтирования, тип файловой системы, условия монтирования (по умолчанию, автоматическое, пользователем и т.д.) и параметры резервного копирования. Файл этот может выглядеть примерно так:
/dev/hda1 /mnt/DOS_hda1 vfat user,exec,conv=auto 0 0
/dev/hda2 / ext2 defaults 1 1
/dev/hda3 swap swap defaults 0 0
/dev/hda4 /home ext2 defaults 1 2
/mnt/floppy /mnt/floppy supermount fs=vfat,dev=/dev/fd0 0 0
none /proc proc defaults 0 0
none /dev/pts devpts mode=0620 0 0
/mnt/cdrom /mnt/cdrom supermount fs=iso9660,dev=/dev/cdrom1 0 0
Из чего можно видеть, что в приведенном примере все разделы ex2fs, раздел подкачки и FAT-раздел монтируются по умолчанию, а для сменных носителей предусмотрена опция supermount, то есть монтирования при обращении и размонтирования - при прекращении его.
Если такая опция не поддерживается, сменные носители требуется монтировать вручную. Для этого дается команда mount с именем устройства и точкой монтирования в качестве аргументов. На пример, с помощью mount /dev/hdc /mnt/cdrom монтируется CD ROM, подключенный в качестве мастера ко второму каналу IDE; содержимое его после этого можно будет увидеть в каталоге /mnt/cdrom. А перед извлечением сменного носителя (во избежание тяжких последствий, его следует размонтировать командой umount с точкой монтирования в качестве аргумента. Разумеется, при этом обращений к файлам на носителе быть не должно.
Для пользователя наиболее важен каталог /usr (кроме его домашнего, разумеется). Если просмотреть его внимательно, можно обнаружить в нем многочисленные повторения. Например, каталоги /usr/X11R6/bin и /usr/bin/X11 кажутся идентичными по содержанию, так же как /usr/X11R6/lib/X11 и /usr/lib/X19. Возникает естественное желание стереть излишки для освобождения дискового пространства. Однако выполнить его в режиме обычного пользователя не удастся без дополнительных манипуляций. А некоторые каталоги (например, /root) не удается даже просмотреть. Потому что все файлы в Linux (а все, что есть в Linux, как говорилось, - это файлы) имеют еще одно непременное свойство (также зафиксированное в inode) - права доступа. Именно понятие прав доступа вызывает наибольшие сложности у новичков в Linux. Обычный случай - только что созданный самолично или скопированный файл не удается открыть, удалить или переместить.
Права доступа разделяются на права принадлежности и права действия. Первые определяются для владельца файла (owner), группы пользователей (group) и всех прочих (other). В отношении же действия существуют права на чтение (read), изменение (или запись, write) и исполнение (execute).
Владелец файла - это пользователь, создавший его или скопировавший. По умолчанию он обычно получает на него все права. Которые подразумевают возможность просмотреть его, модернизировать и записать изменения, а также - исполнить; исполнение для одиночного файла - это возможность запуска бинарной программы или скрипта, для каталога - возможность перейти в этот каталог и просмотреть содержимое. Единственное, чего не может владелец - изменить права принадлежности (сделать владельцем своих файлов другого пользователя). Это - привилегия исключительно администратора.
Группа обычно определяется как пользователи, работающие над общим проектом; Группа обычно по умолчанию получает право чтения и исполнения, но не изменения файла или каталога.
Категория прочие имеют право прочитать файл, но не изменить или выполнить его.