Операционные системы
Теория: Файловая система: устройство, уровни и механизмы
Когда программа пишет файл на диск, операционной системе нужно не просто “записать байты”, а знать, где они лежат, кто их может читать и как потом всё это восстановить после сбоя. Для этого в ядре есть отдельная подсистема — файловая система. Она решает три задачи: где физически размещать данные, как быстро их находить и как сохранить согласованность, если система внезапно выключится.
От байтов к структуре
Когда файловая система создаётся, она делит пространство раздела на несколько зон. У каждой своя роль: superblock, inode table, data blocks и журнал. Эти области — скелет файловой системы. Именно благодаря им ядро знает, где искать файлы, как проверять их целостность и как восстанавливаться после сбоев.
Superblock — это паспорт всего раздела. В нём хранится ключевая информация: размер файловой системы, количество inode и блоков, тип (ext4, xfs), время последнего монтирования и состояние структуры. Без него ядро не сможет понять, как читать данные с диска. Если суперблок повреждён, система не сможет смонтировать раздел. Чтобы защититься, ext4 хранит несколько копий в разных местах. Проверить, где они находятся, можно командой:
dumpe2fs выводит техническое описание раздела, а grep -i superblock оставляет только строки с адресами суперблоков. Первая строка — основной, остальные — резервные копии. Если основной повреждён, раздел можно восстановить одной из них:
Так файловая система берёт резервный суперблок и восстанавливает структуру. Этот механизм — первая линия защиты от потери данных.
Inode table — это каталог метаданных. Каждый файл и каталог имеет собственный номер inode. Внутри него хранятся права доступа, владелец, время изменения, размер и список блоков, где лежат реальные данные. Каталог, по сути, — это таблица пар «имя → inode». Чтобы увидеть, как это работает, можно создать файл и посмотреть его inode:
Первая колонка — номер inode. Это связующее звено между именем и содержимым файла. Теперь создадим жёсткую и символическую ссылки:
report.txt и backup.txt будут иметь одинаковый inode — это два имени одного и того же файла. link.txt получит свой inode, потому что это отдельный объект, где просто записан путь report.txt. Если удалить оригинал:
Данные сохранятся — inode жив, пока на него есть хотя бы одна ссылка. Это наглядно показывает, что имя файла — лишь ярлык, а не сами данные.
Data blocks — это содержимое файлов. Это байты, которые пользователь записывает на диск. Один файл может занимать десятки или сотни блоков, и они не обязаны идти подряд. Файловая система сама следит, какие блоки принадлежат какому файлу. Чтобы убедиться в этом, можно проверить расположение блоков:
Если файл маленький, он займёт один блок. Если большой, в выводе появятся несколько участков — extents. Каждый из них указывает, где именно на диске лежит кусок файла. Это и есть фрагментация: данные могут быть разбросаны, но файловая система хранит их адреса и соединяет воедино при чтении.
Журнал — это защита от сбоев. Он хранит список операций, которые ещё не были окончательно записаны в таблицы данных. Если внезапно отключится питание, система при следующем запуске посмотрит в журнал и завершит недописанные операции. Проверить наличие журнала можно так:
Вывод покажет, что раздел имеет журнал и где он хранится. Это может быть отдельный inode, например с номером 8. Посмотреть его можно:
Там видно, сколько блоков занимает журнал и где они расположены. Если смонтировать файловую систему, создать пару файлов и резко выключить машину, при следующем запуске система восстановится автоматически — ext4 применит журнал и вернёт состояние, в котором все операции либо завершены, либо откатились.
Таким образом, каждая часть файловой системы выполняет свою роль. Superblock описывает всю структуру, inode хранит метаданные, data blocks содержат данные, а журнал защищает от сбоев. Эти механизмы — основа надёжности Linux-файловых систем. Без них невозможно было бы ни хранить, ни восстанавливать данные, ни обеспечивать целостность при миллионах операций чтения и записи.

