Файловая система: разделы, файлы и каталоги

Фрагментация

Любая файловая система так или иначе ищет компромисс между бесконтрольной фрагментацией, как в системе FAT, и полным запретом на фрагментацию, как в файловой системе ОС RT-11. Одной из проблем FAT является необходимость регулярно дефрагментировать раздел, а в файловой системе RT-11 приходилось регулярно выполнять программу squeese, которая записывала друг за другом, последовательно, все файлы, разбросанные по диску. Фрагментация FAT приводила к снижению производительности ввода-вывода, а запрет на фрагментацию в RT-11 делал невозможным запись на диск большого файла, даже если на диске имелось полно участков, размер которых был лишь немногим меньше его длины, так как файл должен был быть записан только в последовательно расположенные блоки.

В файловой системе UFS проблема фрагментации решается очень изящно. Фактически, фрагментация диска редко превышает 1-2% от его объема, что в мире Windows считается превосходным показателем.

Как удается достичь такого? Нужно ли что-то делать системному администратору, чтобы фрагментация не мешала производительности в UNIX?

Надо отметить, что термин "фрагментация" в UNIX означает явление, совсем не похожее на фрагментацию в FAT. В UFS, если на диск записывается файл размером меньше блока, ему выделяется фрагмент блока, но фактически "резервируется" целый блок, и файл, таким образом, имеет резерв для расширения до размера блока. Файлы размером больше блока записываются в свободные (по-возможности, последовательные) блоки файловой системы. Однако размер файла не всегда кратен длине блока, поэтому последний из блоков, в которые записан файл, будет, скорее всего, заполнен не до конца. В этот блок в UFS можно записать фрагмент другого файла. В этом смысле "фрагментом" файла в UFS называется часть файла, меньшая по размеру, чем блок. Фрагменты одного файла не могут храниться в разных блоках. Это иллюстрирует рис. 6.1.

Рис. 6.1. Фрагментация в UFS

Индексный дескриптор хранит достаточно информации для того, чтобы идентифицировать не только блок, но и номер фрагмента в блоке, когда речь идет о размещении файла на диске.

Фрагментации в том смысле, в котором она мучает пользователей Windows, в файловой системе UFS не бывает, так как драйвер файловой системы сам заботится о том, чтобы размещать файл по-возможности в пределах одного цилиндра.

Чтобы выяснить, много ли фрагментов (в понимании UFS) на разделе, можно использовать команду fsck -n.

Для уменьшения числа фрагментов (в понимании FAT), т.е. частей файла, записанных на разделе в разных цилиндрах вдали друг от друга, и для записи файла в последовательные блоки следует воспользоваться коммерческими программами дефрагментации (см., например, http://www.eaglesoft.com/products.html - только для платформы SPARC) или выполнить резервное копирование всех файлов раздела и обратное их восстановление посредством программ ufsdump / ufsrestore.

Изменение размеров раздела

Для изменения размеров раздела UFS можно воспользоваться программой growfs. Если же изменить размер раздела по какой-либо причине не представляется возможным, следует установить новый диск и перенести часть информации на него, возможно, создав соответствующие символические ссылки на переполненном разделе. Подробнее об изменении размеров разделов дисков и повышении их производительности сказано в "лекции 7" курса "Администрирование ОС Solaris".

Дерево каталогов

Все файлы в UNIX организованы древовидно: всегда существует корневой каталог, который обозначается "/". В нем есть подкаталоги. Обычно используются подкаталоги, перечисленные в табл. 6.1.

Каталог /bin в Solaris является символической ссылкой на каталог /usr/bin.

Характерным свойством Solaris является выделение отдельного каталога /exports, в котором сосредотачиваются разделяемые по сети подкаталоги, доступные для пользователей других компьютеров. Каталог /opt, куда устанавливается некоторое дополнительное программное обеспечение (от optional, необязательное) тоже есть в системах Solaris, но отсутствует во многих других системах UNIX.

Каталог для временных файлов /tmp монтируется в Solaris на отдельную виртуальную файловую систему типа tmpfs. Это особый тип файловой системы. Если в системе есть свободная оперативная память, то драйвер tmpfs хранит данные, записанные на файловую систему этого типа, в оперативной памяти, а не диске. Если объем свободной памяти сокращается и она начинает требоваться другим программам, файлы из tmpfs записываются на раздел свопинга. Получается, что файлы, размещенные в файловой системе типа tmpfs, всегда занимают остаток оперативной памяти системы, для того чтобы она использовалась эффективно. Если свободной памяти нет, tmpfs размещается в пространстве свопинга.

Это автоматически приводит к тому, что записанные в файловую систему tmpfs файлы теряются после перезагрузки. Поэтому не следует хранить в /tmp какие-либо полезные файлы.

Скорость работы файловой системы tmpfs высока, т.к. часто все ее файлы физически расположены в оперативной памяти. Вследствие этого кэширование файлов на tmpfs не производится: они и так хранятся не на диске.

Казалось бы, использование tmpfs таит в себе резерв увеличения производительности любого приложения, поскольку достаточно записать данные в каталог /tmp и работать с ними там, чтобы скорость доступа к данным возросла многократно. На самом деле это не так, потому что чтение и запись любых дисков кэшируется, и лишь для некоторых приложений использование tmpfs оправдано. Несомненно увеличивается быстродействие компиляторов и других программ с большими объемами промежуточных файлов - но они и так используют /tmp для хранения временной информации в процессе работы.

По умолчанию Solaris применяет tmpfs только для /tmp. При этом система избегает существенного объема дискового ввода-вывода, так как /tmp используется для временных файлов различных программ.

Внимание: создание отдельного раздела /tmp на диске приведет к тому, что /tmp не будет создан системой автоматически с типом файловой системы tmpfs и производительность системы может уменьшиться!