Выделение индексных дескрипторов

Если создаваемый индексный дескриптор относится к каталогу, система ищет группы блоков с большим свободным пространством и маленьким отношением количества каталогов к количеству обычных файлов. Если создаваемый индексный дескриптор относится к обычному файлу, ФС старается поместить его в ту же группу блоков, где находится родительский каталог [18].

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

Дескрипторы каталогов стараются помещать в первую группу гибкой группы блоков, а дескрипторы обычных файлов – во все остальные (т. е. начиная со второй).

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

Функция множественного выделения блоков хранит последние N выделений в памяти. Их можно просмотреть в файле /proc/fs/ext4/<dev>/mb_history. В истории сохраняются данные о выделении и удалении блоков, о предварительном резервировании и снятии резервирования [18].

Журналирование

Структуры журнала описаны в заголовочном файле jbd2.h. Файл находится по адресу /usr/include/linux/jbd2.h или /usr/src/linux-headers-2.6.31-17/include/linux/jbd2.h (зависит от версии ядра системы). Журнал для файловой системы может быть и внешним, хранимым на отдельном блочном устройстве.

В ext3 и ext4 используется «физическое журналирование», т. е. в качестве основной единицы ведения журнала используется физический блок. Подход, когда хранятся только изменяемые байты, а не целые блоки, называется «логическим журналированием» (используется, например, XFS).

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

Транзакции являются групповыми операциями, выполняемыми или невыполняемыми как одна единая операция, т. е. атомарно. Журналируемые файловые системы (ext3, NTFS) в случае сбоя делают автоматический «откат» при следующей загрузке, и потери кластеров/блоков не происходит. Создание/удаление/переименование файла – это атомарные операции, которые не могут допустить промежуточных состояний. А вот перемещение файла или запись на диск – более сложные операции. Поддержка транзакций не может застраховать от потери записываемых данных.

Журнал состоит из транзакций, имеющих непрерывно возрастающие номера. Как только достигнут конец журнала, запись начинается сначала. Таким образом, журнал – это файл с круговой записью. Если система была размонтирована без ошибок, то запись всегда начинается с самого начала [15].

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

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

Существует еще два вида дескрипторов: блоки отмены и блоки, содержащие тэги (иногда их называют просто дескрипторами). Блоки отмены заполняются номерами блоков, которые должны быть удалены из журнала во время этой транзакции. Дескриптор состоит из последовательности тэгов и идет перед блоками с метаданными.

Тэг – это структура, которая определяет последовательность журнальных блоков (не блоков файловой системы), данные с которых должны быть записаны в указанные блоки файловой системы [16]. Номер журнального блока, который должен быть записан в указанный блок файловой системы, определяется порядковым номером тэга в дескрипторе. Структура тэга определена в заголовочном файле jbd2.h как journal_block_tag_s и приведена в табл. П.2.16.

Таблица П.2.16

Структура тэга

Размер, байт	Смещение	Назначение
4	0 (0h)	Номер блока на диске
4	4 (4h)	Флаги
4	8 (8h)	Если включена поддержка 48-битной адресации, в тэг записываются старшие значащие биты номера блока

Первый блок журнала содержит «журнальный суперблок». Его структура определена в заголовочном файле jbd2.h как journal_superblock_t и приведена в таблице П.2.17.

Таблица П.2.17

Формат журнального суперблока

Размер, байт	Смещение	Назначение
12	0 (0h)	Заголовок (одинаков для всех дескрипторов)
4	12 (Ch)	Размер блоков журнального устройства. Блоки журнала отличаются от блоков файловой системы
4	16 (10h)	Количество блоков в журнальном устройстве
4	20 (14h)	Первый блок журнала, содержащий информацию
4	24 (18h)	Первый ID подтверждения, ожидаемый журналом
4	28 (1Ch)	Номер блока начала журнала
4	32 (20h)	Код ошибки (устанавливается функцией jbd2_journal_abort() )
Следующие поля действительны только для журнального суперблока версии 2
4	36 (24h)	Флаги compat
4	40 (28h)	Флаги incompat
4	44 (2Ch)	Флаги rocompat
16	48 (30h)	Журнальный UUID
4	64 (40h)	Число файловых систем, совместно использующих журнал
4	68 (44h)	Номер блока динамической копии суперблока журнала
4	72 (48h)	Максимальное число журнальных блоков на транзакцию
4	76 (4Ch)	Максимальное число блоков с данными на транзакцию
176	80 (50h)	Заполнение
16х48	256 (100h)	ID всех файловых систем, совместно использующих журнал

На рис. П.2.8 приведен фрагмент дескриптора, содержащего тэги. Номера физических блоков выделены подчеркиванием.

0x00094000 C0 3B 39 98 00 00 00 01 : 00 01 62 0D 00 00 04 BC .;9.......b.....

0x00094010 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 ................

0x00094020 00 00 00 00 00 00 05 E6 : 00 00 00 02 00 00 04 A5 ................

0x00094030 00 00 00 02 00 00 18 6B : 00 00 00 02 00 00 04 BB .......k........

0x00094040 00 00 00 02 00 00 0E 69 : 00 00 00 02 00 00 05 84 .......i........

0x00094050 00 00 00 02 00 08 02 02 : 00 00 00 02 00 08 00 23 ...............#

0x00094060 00 00 00 02 00 00 02 74 : 00 00 00 02 00 08 00 21 .......t.......!

0x00094070 00 00 00 02 00 00 03 F5 : 00 00 00 02 00 00 02 80 ................

Рис. П.2.8. Фрагмент журнального блока-дескриптора

Заголовок журнала имеет тот же вид, что и заголовки остальных дескрипторов. Заголовок определен в файле jbd2.h как структура journal_header_s. Формат заголовка дескриптора приведен в табл. П.2.18.

Таблица П.2.18

Формат заголовка журнального дескриптора

Размер, байт	Смещение	Назначение
4	0 (0h)	Магическое число 0xc03b3998 (первые 4 байта /dev/random)
4	4 (4h)	Тип дескриптора: 1 — дескриптор-тэг или просто дескриптор; 2 — подтверждение; 3 — суперблок версия 1; 4 — суперблок версия 2; 5 — блок отмены
4	8 (8h)	Номер последовательности

Существует несколько режимов журналирования для файловых систем ext3/ext4. Режим работы журнала определяется на этапе монтирования.

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

2. Ordered. В этом режиме журналируются только метаданные, но не содержимое файлов. Однако ФС гарантирует, что содержимое файла будет записано на диск до того, как метаданные, относящиеся к этой транзакции, будут помечены как подтвержденные. Этот режим используется по умолчанию в большинстве дистрибутивов Linux. Если происходит пропадание питания или критическая ошибка ядра во время записи файла, журнал при следующем включении находит новый файл, создание которого не было подтверждено, и запускает процесс очистки, т.е. может записать в журнал подтверждение. Однако бывают ситуации, когда файл перезаписан поверх другой информацией. В этом случае может быть восстановлено промежуточное состояние файла. Худший из случаев – если в восстановленном файле будут перемешаны старые и новые данные.

3. Writeback. Журналируются только метаданные. Содержимое файла может быть записано на диск как до, так и после того, как обновляется журнал. В результате файлы, записанные непосредственно перед крахом системы, могут оказаться поврежденными. Например, файл, присоединенный к другому, может иметь в журнале большую длину, чем есть на самом деле, таким образом, конец файла забивается мусором. Также после восстановления журнала могут неожиданно появиться старые версии файлов. Однако во многих случаях разрыв в синхронизации между журналом и данными невелик. Например, JFS по умолчанию использует именно этот режим.

В Ext3 не предусмотрено контрольного суммирования блоков журнала. Недостаток такого метода в том, что если при пропадании питания будут повреждены какие-то блоки журнала, но записан блок подтверждения, система при следующей загрузке посчитает, что журнал не содержит ошибок, и проведет неверные транзакции. В ext4 при несовпадении контрольных сумм журнала транзакция не состоится, что предотвращает запись поврежденных данных на диск [17].

Контрольные суммы транзакций хранятся в блоке подтверждения. Тип контрольной суммы определяется заголовком этого блока и может принимать значения: CRC32, MD5, SHA1.

Журнал необходим файловой системе для сохранения целостности метаданных, в том числе даже после сбоя системы, но не для восстановления целостности данных пользователя, например данных, по неосторожности удаленных с диска. Существуют программные продукты, которые могут восстанавливать файлы, анализируя журнал, иногда с помощью довольно сложных эвристических алгоритмов, однако полной гарантии восстановления они не дают [18].

275