ехtЗ во многом напоминает ext2, но отличается поддержкой журналирования.
В начале диска расположен загрузочный сектор, который на незагрузочных разделах может быть пустым. За ним по смещению 1024 байта от начала первого сектора лежит суперблок (super-block), содержащий ключевую информацию о структуре файловой системы.
В первую очередь нас будет интересовать 32-разрядное поле `s_log_bock_size`, расположенное по смещению 18h байтов от начала суперблока. Здесь хранится размер одного блока (blосk).
В естественных единицах это будет звучать так: `block_size = 200h << s_log_block_size` (байт). То есть если `s_log_block_size` равен нулю, размер
одного блока составляет 400h байтов или два стандартных сектора. Структура дискового тома, отформатированного под extЗfs, показана в листинге
```
| смещение | размер | описание |
| -------------| -------------| -------------|
| 0 | 1 boot record | ; Загрузочный сектор |
| -- blосk group 0 -- | Группа блоков 0 |
| (1024 bytes) | 1 superblock | Суперблок|
| 2 | 1 group descriptors | Дескриптор группы |
| 3 | 1 blосk bitmap | Карта свободных блоков |
| 4 | inode bitmap | Карта свободных inode |
| 5 | 214 inode tаblе | Массив inode |
| | | (сведения о файлах) |
| 219 | 7974 data blocks | Блоки данных |
| | | (файлы, каталоги) |
```
Вслед за суперблоком идут дескрипторы групп (group descriptors) и карты свободного пространства (blосk bitmap/inode bitmap). В extЗfs (как и многих других файловых системах из мира UNIX) так называемый индексный дескриптор (inode) играет ту же самую роль, что и файловая запись в NTFS. Здесь сосредоточена вся информация о файле, кроме его имени: тип файла (обычный файл, каталог, символьная ссьлка и т. д.), его логический и физический размер, схема размещения на диске, время создания, модификации, последнего доступа или удаления, права доступа, а также ссылки на файл. Формат представления inode в ехtЗ
| смещение | размер | описание |
| -------------| -------------| -------------|
| 0 | 2 i_mode | Формат представления |
| 2 | 2 i_uid | Uid пользователя |
| 4 | 4 i_size | Размер файла в байтах |
| 8 | 4 i_atime | Время последнего доступа к файлу |
| 12 | 4 i_ctime | Время создания файла |
| 16 | 4 i_mtime | Время модификации файла |
| 20 | 4 i_dtime | Время удаления файла |
| 24 | 2 i_gid | Gid групп |
| 26 | 2 i_links_count | Количество ссылок на файл (0 - файл удален) |
| 28 | 4 i_blocks | Количество блоков, принадпежащих файлу |
| 32 | 4 i_flags | Различные флаги |
| 36 | 4 i_osdl | Значение, зависящее от ОС |
| 40 | 12х4 i_bосk | Ссылки на первые 12 блоков файла |
| 88 | 4 i_iblock | 1x INDIRECT BLOCK |
| 92 | 4 i_2iblock | 2x INDIRECT BLOCK |
| 96 | 4 i_3iblock | 3x INDIRECT BLOCK |
| 100 | 4 i_generation | Поколение файла (используется NFS) |
| 104 | 4 i_file_acl | Внешние атрибуты |
| 108 | 4 i_dir_acl | higer size |
| 112 | 4 i_faddr | Положение последнего фрагмента |
| 116 | 12 i_osd2 | Структура, зависящая от ОС |
Первые 12 блоков, занимаемых файлом, называются непосредственными блоками. Они хранятся в массиве DIRECT BLOCKS непосредственно в теле inode. Каждый элемент массива представляет собой 32-битовый номер блока. При среднем значении BLOCK_SIZE, равном 4 Кбайт, непосредственные блоки могут адресовать до 4х12 = 48 Кбайт данных. Если файл превышает этот размер, создаются один или несколько блоков косвенной адресации (INDIRECT BLOCK). Первый блок косвенной адресации (lx INDIRECT BLOCK или просто INDIRECT BLOCK) хранит ссылки на другие непосредственные блоки. Адрес этого блока хранится в поле i_indirect_block в inode. Как легко вычислить, он адресует порядка BLOCK_SIZE/sizeof (DWORD) * BLOCK_SIZE = 4096/4 *4 Мбайт данных. Если этого окажется недостаточно, создается косвенный блок двойной косвенной адресации (2х INDIRECT BLOCK или DOUBLE INDIRECT BLOCK), хранящий указатели на косвенные блоки, что позволяет адресовать (BLOCK_SIZE/sizeof(DWORD))*2* BLOCK_SIZE =4096/4 * 4096 = 4 Гбайт данных. Если же и этого все равно недостаточно, создается блок тройной косвенной адресации (3х INDIRECT BLOCK или TRIPLE INDIRECT BLOCK), содержащий ссылки на блоки двойной косвенной адресации.
Иерархия непосредственных блоков и блоков косвенной адресации показана на рисунке.
Имя файла в inode не хранится. Ищите его внутри каталогов, представляющих собой массив записей. Формат представления массива каталога
| смещение | размер | описание |
| -------------| -------------| -------------|
| 0 | 4 inode | Ссылка на inode |
| 4 | 2 rec_len | Длина данной записи |
| 6 | 1 name_len | Длина имени файла |
| 7 | 1 file type | Тип файла |
| 8 | name | Имя файла |
При удалении файла операционная система находит соответствующую запись в каталоге, обнуляет поле inode и увеличивает размер предшествующей записи (поле rec_len) на величину удаляемой записи. Таким образом, предшествующая запись "поглощает" удаленную. Хотя имя файла в течение некоторого времени остается нетронутым, ссьлка на соответствующий ему индексный дескриптор (inode) оказывается уничтоженной. Это создает проблему, т. к. теперь придется разбираться, какому файлу принадлежит обнаруженное имя.
Огдельно стоит поговорить о журнале файловой системы. Он гарантирует целостность файловой системы в случае непредвиденных сбоев. При этом важно понимать, что целостность файловой системы совсем не означает сохранность файлов! Тем не менее наличие журнала играет важную роль при восстановлении данных в ехt3/4, поскольку информация в нем зачастую помогает восстанавливать взаимосвязи элементов каталогов, inode и содержимого файлов (если она, конечно, еще не была затерта новыми событиями файловой системы).
Журнал файловой системы ехtЗ (да и ext4) может работать в трех режимах, и от выбора будет зависеть как надежность, так и производительность:
* обратной записи - в журнал вносится только общая информация об операциях (метаданные), причем асинхронно по отношению к изменению в самих данных;
* упорядочивания - в журнал также вносятся только метаданные, но перед записью изменений в файле на диск;
* полного журналировани.я - в журнал записываются и метаданные, и изменения в самом файле. Этот вариант, соответственно, самый "прожорливый", но только он может обеспечить целостность данных. Два предыдущих лишь ускоряют выявление ошибок ФС при проверке утилитой fsck и позволяют восстановить целостность файловой системы, но не содержимого хранящихся файлов
В самом индексном дескрипторе при удалении файла тоже происходят большие изменения. Число ссьmок (i_links_count) обнуляется и обновляется поле последнего удаления (i_dtime). Все блоки, принадлежащие файлу, в карте свободного
пространства (blосk bitmap) помечаются как неиспользуемые, после чего данный inode также освобождается(обновляется inode bitmap).
### ext4
Одно из главных улучшений четвертой расширенной файловой системы - исполь зование экстентов вместо карты свободных/занятых блоков, благодаря чему она намного эффективнее управляется с большими файлами, что улучшает масштаби руемость на разделы больших объемов. В то же время механизм экстентов позволя ет уменьшать фрагментацию файлов, копируя фрагментированные части в непре рывные экстенты.
Также в ext4 появился механизм контрольных сумм журнала, гарантирующий, что в файловую систему будут внесены корректные изменения. Еще ext4 может рабо тать вообще без журнала, что немного улучшает ее производительность, но неиз бежно снижает надежность файловой системы. Тем не менее данный режим можно назвать более предпочтительным для устройств на основе флеш-памяти, поскольку очень частые изменения файла журнала расходуют ресурс ячеек памяти.
Структура блоков ext4 не сильно отличается от имеющейся в ехtЗ. Немного большие изменения внесены в структуру индексных дескрипторов. Во-первых, она приобрела новые поля, стала вдвое объемнее и занимает минимум 256 байт. Это позволяет ей хранить, например, метки времени с наносекундной точностью (раньше бьmа точность до секунды), счетчик изменений файла, версию inode, а также ее контрольную сумму. Сами же номера inode стали 48-битовыми, благодаря чему поддерживаются разделы до 1 Эбайт при блоке в 4 КБайт.
А мы заметим, что вместо карты блоков в inode ext4 по смещению Ох28 расположилось дерево экстентов i_block[EXT4_N_BLOCKS=15J. Экстенты определяют непрерывный участок из нескольких расположенных друг за другом блоков. Один экстент может адресовать до 128 МБайт при блоке в 4 Кбайт. Всего в одном индексном дескрипторе может храниться 4 экстента, а если их не хватает, то используется до экстентов, напо минающее схему косвенной адресации блоков в
струюуры служебных данных на ехt4-разделе можно посмотреть с помощью команды fsstat
По сути, процесс восстановления файлов (вернее, проблемы, препятствующие это му), тот же, что и в ехtЗ. Однако появилась утилита с замечательным названием ext4magic (которая умеет работать и с разделами ехtЗ). Она уже несколько лет не обновлялась, но и структуры ФС по большей части сформировались уже давно и изменяются незначительно. Эта программа в отдельных случаях способна спасать не только файлы, но и их названия вместе со всеми атрибутами! Важную роль при восстановлении играет состояние журнала, которое позволяет реконструировать взаимосвязь файлов с описывающей их служебной информацией - элементами каталогов и индексными дескрипторами. Естественно, чем меньше времени и из менений в файловой системе произошло с момента удаления файлов, тем больше вероятность их успешного восстановления. После случайного удаления файла следует как можно быстрее отмонтировать ФС, по возможности создать образ восстанавливаемого раздела и работать уже с ним.