Алексей Стахнов - Linux Страница 17

В третьем проходе проверяются связи каталогов. Программа e2fsck проверяет пути каждого каталога по направлению к корневому. В этом же проходе проверяется запись ".." для каждого каталога. Все каталоги, не имеющие связи с корневым каталогом, помещаются в каталог /lost+found.

В четвертом проходе e2fsck проверяет счетчики ссылок для каждого индексного дескриптора. Все неудаленные файлы с нулевым счетчиком ссылок также помещаются в каталог /lost+found.

Журналируемые файловые системы

Основная цель, которая преследуется при создании журналируемых файловых систем, состоит в том, чтобы обеспечить как можно большую вероятность быстрого восстановления системы после сбоев (например, после потери питания). Дело в том, что если происходит сбой, то часть информации о расположении файлов теряется, поскольку система не успевает записать все изменения из буфера на диск. После сбоя утилита fsck должна проверить все диски, которые не были корректно демонтированы, с целью восстановления потерянной информации. При современных объемах жестких дисков, исчисляемых десятками гигабайт, на проверку двух-трех таких дисков может уйти слишком много времени. Кроме того, нет гарантии, что все данные удастся восстановить.

В журналируемых файловых системах для решения этой проблемы применяют транзакции, которые хорошо известны всем программистам баз данных. Идея транзакции достаточно проста – существует набор связанных операций, называемых транзакцией, и эта группа операций является атомарной (неделимой). Таким образом, транзакция является успешной (завершенной) в том случае, если все операции, составляющие транзакцию, завершились успешно. Но это еще не все. Система ведет журнал, в котором отражаются все действия с данными и все изменения данных протоколируются. В случае сбоя на основании журнала можно вернуть систему в безошибочное состояние.

Основное отличие транзакций из области баз данных от транзакций, применяемых в журналируемых файловых системах, состоит в том, что в базах данных в журнале сохраняются изменяемые данные и вся управляющая информация, а в файловых системах – только мета-данные: индексные дескрипторы изменяемых файлов, битовые карты распределения свободных блоков и свободных индексных дескрипторов.

Файловая система Ext3

По большому счету, файловая система Ext3 не является новой файловой системой. Это похоже на ситуацию с файловой системой FAT 16/FAT 32 – они совместимы, но проблема решена экстенсивным путем. Было необходимо срочно создать журналируемую файловую систему. Если начинать с нуля – долго и накладно, тогда сделали для Ext2 несколько десятков специальных функций и назвали все это Ext3 – получился непонятный гибрид.

Вроде бы добавились журналирующие функции – но не в том объеме, в каком хотелось. И узкие места Ext2 остались: оптимизация использования дискового пространства, ограничение на размер файла и т. п. Пока же общественность (fido7.ru.linux) более склоняется к использованию других журналируемых файловых систем.

Файловая система ReiserFS

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

Поскольку в файловой системе используется простой связный список, то время поиска информации линейно зависит от длины списка. Таким образом, чем длиннее список (к примеру, файлов в каталоге), тем дольше идет поиск необходимого элемента.

В системе ReiserFS применяются так называемые "сбалансированные деревья" или "B+Trees", время поиска в которых пропорционально не количеству объектов, а логарифму этого числа. В сбалансированном дереве все ветви имеют одинаковую длину. ReiserFS использует сбалансированные деревья для хранения всех объектов файловой системы: файлов в каталогах, данных о свободных блоках и т. д. Это позволяет существенно повысить производительность обращения к дискам.

Кроме того, система ReiserFS является журналируемой, т. е. в ней решена проблема быстрого восстановления после сбоев. Решена в ReiserFS и проблема с ограничением на размер файла. По всей видимости, именно эта файловая журналируемая система в ближайшее время станет стандартом de-facto для многих дистрибутивов Linux.

Ссылки

• e2fsprogs.sourceforge.net – утилиты файловой системы Ext2.

• ftp.uk.linux.org/pub/linux/sct/fs/ji\'s/ – код и документация Ext3.

• www.atni.csiro.au/~rgooch/linux/docs/vfs.txt – обзор виртуальной файловой системы.

• www.osp.ru/pcworld/2000/02/064.htm – Виктор Хименко. Файлы, файлы, файлы. Обзор файловых систем.

• www.linux-ve.chat.ru – виртуальная библиотека Linux.

Глава 5 Дерево каталогов Linux

Эта глава полностью посвящена структуре и размещению каталогов и файлов в Linux. Поскольку для различных дистрибутивов структура может слегка отличаться, для определенности будем рассматривать дистрибутив Red Hat 7.1.

Для того чтобы ориентироваться в Linux, необходимо хорошо представлять себе структуру и размещение каталогов и файлов. Эти параметры для UNIX и Linux описаны в документе "Filesystem Hierarchy Standard – Version 2.2 final", Filesystem Hierarchy Standard Group, edited by Rusty Russell and Daniel Quinlan, редакция от May 23, 2001. Дальнейший текст в основном базируется на этом документе.

Все файлы можно разделить по двум признакам – доступность (shareable, разделяемость) на сетевом уровне и изменяемость/неизменность содержимого.

Соответственно, для каждого признака можно ввести свои понятия:

•  разделяемые данные – те, которые могут использовать несколько хостов одновременно, т. е. данные, доступные для других хостов через сеть;

•  неразделяемые данные – как правило, специфичные для каждого хоста, недоступные через сеть для других хостов;

•  статические данные – включают системные файлы, библиотеки, документацию и другое, что не изменяется без вмешательства администратора;

•  динамические (переменные) данные – все то, что может изменяться пользователем.

Эти признаки взаимно ортогональны, в табл. 5.1 приведены некоторые каталоги, соответствующие этим признакам.

Таблица 5.1. Признаки данных и каталоги

Как видно из таблицы, каталог /usr – статический разделяемый, а каталог /var/lock – динамический неразделяемый. По этим признакам можно распределить все каталоги в файловой системе, о чем и будет упоминаться в соответствующих разделах. Однако такое четкое распределение не всегда наблюдается в современных UNIX-системах. Как правило, эта проблема возникает из-за поддержки совместимости со старым программным обеспечением. Каталоги, не удовлетворяющие четкому разделению, будут упомянуты особо.

Иерархия каталогов Linux

В табл. 5.2 приведена иерархия каталогов первого уровня.

Таблица 5.2. Каталоги первого уровня операционной системы Linux

Рассмотрим подробнее иерархию каталогов.

Корневой (Root) каталог

Точка монтирования всей файловой системы. Играет исключительно важную роль в процессе «жизнедеятельности» операционной системы. Для загрузки системы необходимо, чтобы в корневом разделе (корневой раздел в Linux – это аналог диска С: для DOS/Windows – только на него возможно установить операционную систему. И корневой раздел является точкой монтирования корневого каталога) находились утилиты и конфигурационные файлы, необходимые для монтирования других файловых систем. Кроме того, в корневой файловой системе должны присутствовать утилиты, необходимые для создания, восстановления или ремонта файловых систем, а также для административного восстановления (backup) системы с ленты, CD-ROM, дискет и тому подобных носителей. Каталоги /usr, /opt, /var спроектированы так, что они могут размещаться на файловых системах, отличных от корневой. В дистрибутиве Slackware в корневом каталоге по умолчанию находится ядро операционной системы (что на больших винчестерах иногда вызывало определенные проблемы), в дистрибутиве Red Hat ядро операционной системы перенесено в каталог /boot.

Имеется несколько причин, по которым корневую файловую систему рекомендуется делать минимально возможного размера:

• это позволяет монтировать файловую систему с очень маленьких носителей информации (например дискет);

• корневая файловая система не может быть разделяемой, потому что содержит много системно-зависимых конфигурационных файлов. Создание малой по объему корневой файловой системы позволяет сохранить на серверах больше места для разделяемых ресурсов;

• у маленького по объему корневого каталога меньше вероятность пострадать при крахе системы.