Первые 12 блоков, занимаемых файлом, называются непосредственными блоками (для наглядности они выделены полужирным шрифтом). Они хранятся в массиве DIRECT BLOCKS
BLOCK_SIZE
, равном 4 Кбайт, непосредственные блоки могут адресовать до 4×12 == 48
Кбайт данных. Если файл превышает этот размер, создаются один или несколько блоков косвенной адресации (INDIRECT BLOCK
). Первый блок косвенной адресации (1x 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
), содержащий ссылки на блоки двойной косвенной адресации. Иерархия непосредственных блоков и блоков косвенной адресации показана на рис. 8.6 (блок тройной косвенной адресации не показан).Рис. 8.6
. Порядок размещения файла на диске — иерархия непосредственных и косвенных блоков (блок косвенной адресации третьего порядка не показан)По сравнению с NTFS такая схема хранения информации о размещении устроена намного проще. Вместе с тем, она и гораздо "прожорливее". С другой стороны, ее несомненное достоинство по сравнению с NTFS состоит в том, что поскольку все ссылки хранятся в неупакованном виде, для каждого блока файла можно быстро найти соответствующий ему косвенный блок, даже если inode полностью разрушен!
Имя файла в inode не хранится. Ищите его внутри каталогов, представляющих собой массив записей, формат которого представлен в листинге 8.6.
Листинг 8.6. Формат представления массива каталогов
смещение размер описание
-------- ------ --------
0 4 inode ; Ссылка на inode
4 2 rec_len ; Длина данной записи
6 1 name_len ; Длина имени файла
7 1 file_type ; Тип файла
8 ... name ; Имя файла
При удалении файла операционная система находит соответствующую запись в каталоге, обнуляет поле inode
rec_len
) на величину удаляемой записи. Таким образом, предшествующая запись "поглощает" удаленную. Хотя имя файла в течение некоторого времени остается нетронутым, ссылка на соответствующий ему индексный дескриптор (inode) оказывается уничтоженной. Это создает проблему, так как теперь придется разбираться, какому файлу принадлежит обнаруженное имя.В самом индексном дескрипторе при удалении файла тоже происходят большие изменения. Количество ссылок (i_links_count
i_dtime
). Все блоки, принадлежащие файлу, в карте свободного пространства (block bitmap
) помечаются как неиспользуемые, после чего данный inode также освобождается (обновляется inode bitmap
).В ext2fs полное восстановление файлов невозможно, даже если эти файлы были только что удалены. В этом отношении данная файловая система проигрывает как FAT, так и NTFS. Как минимум, теряется имя файла. Точнее говоря, теряется связь имен файлов с их содержимым. При удалении небольшого количества хорошо известных файлов эта проблема остается решаемой. Однако ситуация серьезно осложняется, если вы удалили несколько служебных подкаталогов, в которых никогда ранее не заглядывали.
Достаточно часто индексные дескрипторы назначаются в том же порядке, в котором создаются записи в таблице каталогов. Благодаря наличию расширений имен файлов (.c, .gz, .mpg, и т.д.) количество возможных комбинаций соответствий обычно оказывается сравнительно небольшим. Тем не менее, восстановить удаленный корневой каталог в автоматическом режиме никому не удастся (а вот NTFS с этим справляется без труда).