Linux для пользователя

Таблица 16.8. Некоторые параметры файловых систем новых типов

	Размер блока	Максим. размер файловой системы	Максим. размер файла
Ext3FS	1-4 Кбайт	4 Tбайт	2 Гбайт
XFS	от 512 байт до 64 Кбайт	18 тысяч петабайт	9 тысяч петабайт
JFS	512, 1024, 2048, 4096 байт	от 4 петабайт (при 512-байтных блоках) до 32 петабайт (при 4-килобайтовых блоках)	От 512 Тбайт (при 512-байтовых блоках) До 4 петабайт (при 4-килобайтовых блоках)
ReiserFS	До 64 Кбайт (пока что фиксирован, 4 Кбайт)	4 Гбайт блоков, 16 Тбайт	4 Гбайт, 210 петабайт в ReiserFS (3.6.xx)

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

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

В журналируемых файловых системах для решения этой проблемы применяют технику транзакций, развитую в теории баз данных. Суть этой техники в том, что действие не считается завершенным, пока все изменения не сохранены на диске. А чтобы сбои, происходящие в течение времени, необходимого для завершения всех операций, не приводили к необратимым последствиям, все действия и все изменяемые данные протоколируются. Если сбой все-таки произойдет, то по этому протоколу можно вернуть систему в безошибочное состояние.

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

Файловые системы ext3fs и JFS являются журналируемыми. Надо отметить, что ext3fs не является совершенно новой разработкой, а является просто надстройкой над ext2fs, обеспечивающей ведение журнала и организацию транзакций. Файловые системы XFS и JFS являются открытыми версиями коммерческих файловых систем.

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

Кроме проблемы быстрого восстановления после сбоев, в файловой системе ext2fs имеется еще несколько нерешенных проблем.

Одна из самых насущных - это проблема нерационального использования дискового пространства. Конечно, ext2fs использует диск гораздо более рационально, чем FAT, но, как вам хорошо известно, "памяти много не бывает"!

Собственно проблема возникает из-за следующего противоречия:

• если размер блока выбрать большим (кластер размером 32Кбайт в FAT), то при сохранении большого числа мелких файлов на диске неразумно используется дисковое пространство, так как маленькие файлы (и концы больших файлов) занимают целые блоки (Juan I. Santos Florido в своей статье называет это "внутренней фрагментацией");

• если размер блока выбрать маленьким (512 байт), то снижается производительность ввода/вывода, так как надо прочитать много блоков, которые могут быть разбросаны по диску (это "внешняя фрагментация").

Еще две проблемы, с которыми мы сталкиваемся в файловой системе ext2fs, связаны с поиском. Первая проблема возникает при записи на диск нового файла. Поскольку распределение свободных блоков хранится в виде битовой карты свободных блоков и свободных индексных дескрипторов, то файловая система вынуждена производить последовательный просмотр этих массивов для нахождения свободного места. В худшем случае это может потребовать времени, пропорционального объему диска.

Вторая проблема поиска связана с поиском файлов в больших каталогах. Поскольку файлы мы ищем по именам, приходится последовательно просматривать все записи в каталоге. Время такого поиска тоже пропорционально размеру каталога и вырастает в проблему при больших размерах каталогов.

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

Кроме того, ReiserFS является журналируемой, т. е. в ней решена и проблема быстрого восстановления после сбоев.

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

Глава 17. Обновление ядра

17.1. Что такое ядро и когда его надо менять

Каждый, кто хоть немного интересовался тем, что такое Linux, обязательно встречал в различных руководствах термин "ядро", по-английски - kernel. Ядро - это важнейшая часть Linux, как и любой другой операционной системы, поскольку именно ядро обеспечивает взаимодействие с аппаратной частью компьютера, распределение ресурсов, управление процессами и многое другое. Когда вы загружаете какое-то приложение с жесткого диска в оперативную память, или переключаетесь между уже работающими приложениями, или когда какое-то приложение записывает информацию в файл на диске, операционная система или активное приложение должно запросить доступ к той части аппаратуры, которая ему необходима. Ядро обеспечивает исполнение таких запросов других частей операционной системы и приложений, а также распределяет память между запускаемыми приложениями. Ядро, таким образом, является посредником между аппаратным и программным обеспечением компьютера, обеспечивающим их взаимодействие.

Работа по совершенствованию ядра Linux ведется международным сообществом разработчиков постоянно, и регулярно появляются новые версии ядра. Естественно, что пользователи хотят иметь последнюю (или, по крайней мере, одну из последних) версий ядра ОС и рано или поздно вы приходите к выводу о том, что пора обновить ядро.

Можно задать вопрос: "В каких случаях это необходимо?". Действительно, если система неплохо работает со старым ядром, то стоит ли заниматься его обновлением? Основными причинами, приводящими к выводу о необходимости обновления ядра, являются: