21.6. Новые файловые системы
Файловая система
ext2fs была создана
по образу и подобию файловой системы UNIX (UNIX File System - UFS). Обе они
(особенно UFS) создавались еще в те времена, когда диски и другие физические
носители данных имели довольно маленький (по современным меркам) объем.
Увеличение объема дисков вело к возрастанию объема разделов диска, увеличению
размеров отдельных файлов и каталогов. Это породило ряд проблем, связанных с
ограниченностью внутренних структур данных файловой системы.
Существуют две основных проблемы этого рода:
- Эти структуры не способны работать с носителями информации увеличенного
объема. В них отведено строго фиксированное число бит для хранения данных о
размере дисковых разделов и размерах файлов, фиксированное число бит для
хранения логических номеров блоков и так далее. Как следствие, число файлов и
каталогов и их размер ограничены.
- Вторая проблема связана с производительностью. В силу заложенных в старые
файловые системы алгоритмов решение некоторых задач на носителях увеличенного
объема стало требовать слишком большого времени. Одним из самых характерных
примеров такого рода проблем является трудоемкость восстановления файловой
системы после сбоев (например, после неожиданного отключения питания). Это
восстановление выполняется с помощью программы fsck и для очень больших
дисков стало требовать нескольких часов.
Естественно, что появление этих проблем породило и попытки их решения. Были
разработаны новые типы файловых систем, при создании которых учитывались
требования масштабируемости. Наиболее известными разработками файловых систем
новых типов являются:
- файловая система ext3fs ;
- XFS;
- журналируемая файловая система JFS
фирмы IBM;
- ReiserFS .
В следующей табличке приведены данные по увеличению основных параметров,
обеспечиваемых новыми файловыми системами. Данные заимствованы из статьи Juan I.
Santos Florido "Journal File Systems", опубликованной в 55-ом выпуске Linux
Gazette (July 2000).
| |
Размер блока |
Максим. размер файловой
системы |
Максим. размер файла |
|
Ext3FS |
1KB-4KB |
4Tb |
2GB |
|
XFS |
от 512 байт до 64 KB |
18 тысяч петабайт |
9 тысяч петабайт |
|
JFS |
512, 1024, 2048, 4096 байт |
от 4 петабайт (при 512-байтных блоках) до 32
петабайт (при 4-килобайтовых блоках) |
от 512 терабайт (при 512-байтовых блоках) до 4
петабайт (при 4-килобайтовых блоках) |
|
ReiserFS |
До 64KB
Пока
что фиксирован, 4KB |
4GB of blocks, 16 Tb |
4GB, 2^10 petabytes in ReiserFS
(3.6.xx) |
21.7. Журналируемые файловые системы
Основная цель, которая преследуется
при создании журналируемых файловых систем, насколько я понял, состоит в том,
чтобы обеспечить быстрое восстановление системы после сбоев (например, после
потери питания). Дело в том, что если произойдет такой сбой, то часть информации
о расположении файлов теряется, поскольку не все изменения сразу записываются на
диск. После этого программа
fsck вынуждена просматривать весь диск блок
за блоком (пользуясь битовыми матрицами занятых блоков и индексных дескрипторов)
с целью восстановления потерянных связей. При увеличении размера дисков вдвое,
вдвое увеличивается и время, необходимое для просмотра всего диска. А при тех
объемах, которых достигают современные диски, особенно на серверах, время,
необходимое для того, чтобы просмотреть весь диск, стало недопустимо велико: оно
стало достигать часов и даже суток. А сервер в это время не отзывается! Кроме
того, нет гарантии, что все связи удастся восстановить.
В журналируемых файловых системах для решения этой проблемы применяют технику
транзакций, развитую в теории баз данных. Суть этой техники в том, что действие
не считается завершенным, пока все изменения не сохранены на диске. А чтобы
сбои, происходящие в течение времени, необходимого для завершения всех операций,
не приводили к необратимым последствиям, все действия и все изменяемые данные
протоколируются. Если сбой все-таки произойдет, то по этому протоколу можно
вернуть систему в безошибочное состояние.
Главное отличие в технике транзакций, применяемой в базах данных, от
аналогичной техники, применяемой в журналируемых файловых системах, состоит в
том, что в базах данных сохраняются в протоколе как сами изменяемые данные, так
и вся управляющая информация, в то время как понятие транзакции в файловых
системах подразумевает сохранение только мета-данных: индексных дескрипторов
изменяемого файла, битовых карт распределения свободных блоков и свободных
индексных дескрипторов. Дело в том, что если сохранять все изменяемые данные, то
теряется смысл кеширования записи на диск и уменьшается скорость дисковых
операций. Мета-данные же, во-первых, меньше по размеру, а, во-вторых,
сохраняются в специально выделенной области диска, что позволяет избежать
чрезмерных затрат времени на ведение протокола.
Файловые системы ext3fs и JFS являются журналируемыми. Надо
отметить, что ext3fs не является совершенно новой разработкой, а является
просто надстройкой над ext2fs, обеспечивающей ведение журнала и
организацию транзакций. Файловые системы XFS и JFS являются
открытыми версиями коммерческих файловых систем.
21.8. Файловая система ReiserFS
Кроме проблемы быстрого восстановления
после сбоев, в файловой системе
ext2fs имеется еще несколько нерешенных
проблем. Одна из самых насущных - это проблема нерационального использования
дискового пространства. Конечно,
ext2fs использует диск гораздо более
рационально, чем
FAT, но, как Вам хорошо известно, "памяти много не
бывает"!
Собственно проблема возникает из-за следующего противоречия:
- если размер блока выбрать большим (кластер по 32К в FAT), то при
сохранении большого числа мелких файлов на диске неразумно используется дисковое
пространство, так как маленькие файлы (и концы больших файлов) занимают целые
блоки (Juan I. Santos Florido в своей статье называет это "внутренней
фрагментацией");
- если размер блока выбрать маленьким (512 байт), то снижается
производительность ввода/вывода, так как надо прочитать много блоков, которые
могут быть разбросаны по диску (это "внешняя фрагментация").
Еще две проблемы, с которыми мы сталкиваемся в файловой системе
ext2fs, связаны с поиском. Первая проблема возникает при записи на диск
нового файла. Поскольку распределение свободных блоков хранится в виде битовой
карты свободных блоков и свободных индексных дескрипторов, то файловая система
вынуждена производить последовательный просмотр этих массивов для нахождения
свободного места. В худшем случае это может потребовать времени,
пропорционального объему диска.
Вторая проблема поиска связана с поиском файлов в больших каталогах.
Поскольку файлы мы ищем по именам, приходится последовательно просматривать все
записи в каталоге. Время такого поиска тоже пропорционально размеру каталога и
вырастает в проблему при больших размерах каталогов.
Между тем методы снижения трудоемкости поиска давно разработаны, только надо
для хранения информации о свободных объектах использовать не простые списки, а
несколько более сложные структуры данных. В системе ReiserFS для этого
применяются так называемые "сбалансированные деревья" или "B+Trees", время
поиска в которых пропорционально не количеству объектов (файлов в каталоге или
числа блоков на диске), а логарифму этого числа. В сбалансированном дереве все
ветви (пути от корня до "листа") имеют одинаковую (или примерно одинаковую)
длину. ReiserFS использует сбалансированные деревья для хранения всех
объектов файловой системы : файлов в каталогах, данных о свободных блоках и т.д.
Это позволяет существенно повысить производительность обращения к дискам.
Кроме того, ReiserFS является журналируемой, то есть в ней решена и
проблема быстрого восстановления после сбоев.
Большего об устройстве новых типов файловых систем я пока не могу сказать,
поскольку информации о них довольно мало, а в исходниках копаться...
.gif){kind=small}
