что такое суперблок в ext4

Что такое суперблок в ext4

Информация, хранимая в суперблоке, используется для организации доступа к остальным данным на диске. В суперблоке определяется размер файловой системы, максимальное число файлов в разделе, объем свободного пространства и содержится информация о том, где искать незанятые участки. При запуске ОС суперблок считывается в память и все изменения файловой системы вначале находят отображение в копии суперблока, находящейся в ОП, и записываются на диск только периодически. Это позволяет повысить производительность системы, так как многие пользователи и процессы постоянно обновляют файлы. С другой стороны, при выключении системы суперблок обязательно должен быть записан на диск, что не позволяет выключать компьютер простым выключением питания. В противном случае, при следующей загрузке информация, записанная в суперблоке, окажется не соответствующей реальному состоянию файловой системы.

Суперблок имеет следующую структуру.

Источник

Суперблок в линуксе

Что такое суперблок в Линуксе. Попробуем разобраться на примере файловой системы ext(2|3|4), которая используется в линуксе по-умолчанию. Но для начала рассмотрим несколько простых понятий

Блок файловой системы

После форматирования диска или раздела сектора на диске разделены на небольшие группы. Такая группа секторов называется блоком. Размер блока может быть разным и задается как параметр ключа команды форматирования. Например

Размер блока может быть разным. Это зависит от типа файловой системы

При выборе размера блока нужно учесть ряд моментов

Размер блока влияет на скорость чтения/записи с диска. Представим себе файл размеров в несколько сот мегабайт, который считывается с диска блоками по 1Кб. Тот же файл будет считываться быстрее если размер блока файловой системы будет 4Кб или 8Кб. Это ясно. Поэтому при форматировании имеет смысл задать блок большего размера, если планируется использовать файлы большого размера

Также верно и обратное утверждение. В случае хранения небольших файлов лучше использовать блоки минимального размера

Ядро Linux работает с размером блока файловой системы, а не с размером сектора диска (обычно 512 байт). Важно понимать, что размер блока файловой системы не может быть меньше размера сектора диска и всегда будет кратным ему. Также ядро ожидает, что размер блока файловой системы будет меньше или равно размеру системной страницы

Размер системной страницы можно увидеть выполнив команду

Группы блоков файловой системы

Блоки, о которых мы говорили ранее обьеденяются в группы блоков, что позитивно отражается на операциях чтения/записи так как уменьшается время чтения/записи больших обьемов данных

Файловая система EXT разбивает все доспупное пространство на группы блоков равного размера. Эти группы располагаются последовательно, одна за другой

Количество блоков в группе неизменно и может быть расчитано по формуле

Взглянем на вывод команды mke2fs

Отметим то, о чем говорили выше

Также видны блоки в которых хранятся резервные копии суперблока

Так что же такое суперблок?

Самым простым определением суперблока могло бы быть следующее утверждение

Суперблок — это блок в котором хранятся метаданные файловой системы

Аналогично тому, как i-ноды хранят метаданные о файлах, суперблок хранит метаданные о файловой ситеме. Если вдруг суперблок поврежден, то не возможно будет примонтировать файловую систему. Обычно при загрузке система проверяет суперблок и при необходимости исправляет его, что в результате приводит к корректному монтированию файловых систем

Некоторые данные, которые хранятся в суперблоке. Например

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

Суперблок весьма критичен для файловой системы. Поэтому в каждой блоковой группе есть копии суперблока. Это дает нам право думать, что поврежденный суперблок будет восстановлен всякий раз, когда это будет необходимо

Может показаться, что наличие в каждой блоковой группе резервных копий суперблока приводит к потреблению большого дискового пространства. Для этого в последних версиях систем была реализована функция «sparse_super» целью которой было создание резервных копий в группе блоков 0, 1, 3, 5, 7

Как увидеть, что хранится в суперблоке?

Для этого воспользуемся командой dumpe2fs

Еще один вывод команды показывает информацию о суперблоке

Как восстановить поврежденный суперблок?

Для начала нужно проверить файловую систему утилитой fsck

В случае если fsck обнаружила ошибку чтения суперблока можно попробовать сделать следующее:

Для начала определим где расположены резервные копии суперблока. Для этого выполняем

Далее восстановливаем суперблок из бекапа при помощи e2fsck

В данном случае в блоке 819200 хранится резервная копия суперблока. После применения команды пробуем снова монтировать файловую систему. Либо как вариант использовать ключ sb команды mount, который указывает на расположение копии суперблока

В данном случае считываем копию суперблока из блока 819200

Системный администратор. В сисадминстве с 2000 года. Участник Хабр Q&A и cyberforum

Источник

Что такое суперблок в ext4

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

Блок файловой системы

После форматирования диска или раздела сектора на диске разделены на небольшие группы. Такая группа секторов называется блоком. Размер блока может быть разным и задается как параметр ключа команды форматирования. Например

Размер блока может быть разным. Это зависит от типа файловой системы

При выборе размера блока нужно учесть ряд моментов

Размер блока влияет на скорость чтения/записи с диска. Представим себе файл размеров в несколько сот мегабайт, который считывается с диска блоками по 1Кб. Тот же файл будет считываться быстрее если размер блока файловой системы будет 4Кб или 8Кб. Это ясно. Поэтому при форматировании имеет смысл задать блок большего размера, если планируется использовать файлы большого размера

Также верно и обратное утверждение. В случае хранения небольших файлов лучше использовать блоки минимального размера

Ядро Linux работает с размером блока файловой системы, а не с размером сектора диска (обычно 512 байт). Важно понимать, что размер блока файловой системы не может быть меньше размера сектора диска и всегда будет кратным ему. Также ядро ожидает, что размер блока файловой системы будет меньше или равно размеру системной страницы

Размер системной страницы можно увидеть выполнив команду

Группы блоков файловой системы

Блоки, о которых мы говорили ранее обьеденяются в группы блоков, что позитивно отражается на операциях чтения/записи так как уменьшается время чтения/записи больших обьемов данных

Файловая система EXT разбивает все доспупное пространство на группы блоков равного размера. Эти группы располагаются последовательно, одна за другой

Количество блоков в группе неизменно и может быть расчитано по формуле

Взглянем на вывод команды mke2fs

Отметим то, о чем говорили выше

Также видны блоки в которых хранятся резервные копии суперблока

Так что же такое суперблок?

Самым простым определением суперблока могло бы быть следующее утверждение

Суперблок — это блок в котором хранятся метаданные файловой системы

Аналогично тому, как i-ноды хранят метаданные о файлах, суперблок хранит метаданные о файловой ситеме. Если вдруг суперблок поврежден, то не возможно будет примонтировать файловую систему. Обычно при загрузке система проверяет суперблок и при необходимости исправляет его, что в результате приводит к корректному монтированию файловых систем

Некоторые данные, которые хранятся в суперблоке. Например

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

Суперблок весьма критичен для файловой системы. Поэтому в каждой блоковой группе есть копии суперблока. Это дает нам право думать, что поврежденный суперблок будет восстановлен всякий раз, когда это будет необходимо

Может показаться, что наличие в каждой блоковой группе резервных копий суперблока приводит к потреблению большого дискового пространства. Для этого в последних версиях систем была реализована функция «sparse_super» целью которой было создание резервных копий в группе блоков 0, 1, 3, 5, 7

Как увидеть, что хранится в суперблоке?

Для этого воспользуемся командой dumpe2fs

Еще один вывод команды показывает информацию о суперблоке

Как восстановить поврежденный суперблок?

Для начала нужно проверить файловую систему утилитой fsck

В случае если fsck обнаружила ошибку чтения суперблока можно попробовать сделать следующее:

Для начала определим где расположены резервные копии суперблока. Для этого выполняем

Далее восстановливаем суперблок из бекапа при помощи e2fsck

В данном случае в блоке 819200 хранится резервная копия суперблока. После применения команды пробуем снова монтировать файловую систему. Либо как вариант использовать ключ sb команды mount, который указывает на расположение копии суперблока

В данном случае считываем копию суперблока из блока 819200

Источник

Экстенты, файлы, суперблоки. Как работают файловые системы ext3 и ext4 и как в них восстанавливать данные

Содержание статьи

В 2006 году выш­ла в свет кни­га Кри­са Кас­пер­ски «Вос­ста­нов­ление дан­ных», которая быс­тро ста­ла бес­тсел­лером. Сей­час эта кни­га готовит­ся к пере­изда­нию. Мы пуб­лику­ем отры­вок из этой кни­ги, пос­вящен­ный вос­ста­нов­лению дан­ных в фай­ловых сис­темах ext.

Оши­боч­ное уда­ление фай­лов в *NIX — это дос­таточ­но рас­простра­нен­ное явле­ние, навер­ное, даже более час­тое, чем в мире Microsoft. Под Windows боль­шинс­тво фай­ловых опе­раций выпол­няет­ся вруч­ную с помощью про­вод­ника или дру­гих инте­рак­тивных средств типа FAR или Total Commander. Инте­рак­тивные сре­ды есть и в Linux (KDE, GNOME, XFCE…), но немалая часть фанатов Linux — пок­лонни­ки коман­дной стро­ки. Коман­дная же стро­ка — это регуляр­ные выраже­ния и скрип­ты, то есть авто­мати­зиро­ван­ные средс­тва управле­ния — мощ­ные, удоб­ные и, при неп­равиль­ном исполь­зовании, раз­рушитель­ные. Малей­шая неб­режность — и можешь нав­сегда поп­рощать­ся со сво­ими фай­лами!

Пе­реф­разируя Бул­гакова, мож­но ска­зать: мало того что файл смер­тен, так он еще и вне­зап­но смер­тен! Беда никог­да не пре­дуп­режда­ет о сво­ем при­ходе, и адми­нис­тра­тору при­ходит­ся быть пос­тоян­но начеку. Нес­коль­ко секунд назад все было хорошо: цве­ла вес­на, вин­честер ожив­ленно стре­котал все­ми сво­ими голов­ками, адми­нис­тра­тор отхле­бывал кофе из чер­ной круж­ки с над­писью root, как вдруг сот­ни гигабайт цен­ней­ших дан­ных вне­зап­но раз­летелись на мел­кие осколки. Все силы бро­шены на раз­гре­бание завалов и спа­сение всех, кого еще мож­но спас­ти.

Дос­тупность исходных тек­стов драй­вера фай­ловой сис­темы зна­читель­но упро­щает иссле­дова­ние ее внут­ренней струк­туры, которая, кста­ти говоря, очень прос­та. Поэто­му вос­ста­нов­ление дан­ных на раз­делах ext2/3/4 — задача три­виаль­ная.

Знакомьтесь! Семейство расширенных файловых систем

Из­началь­но Linux был чем‑то вро­де воль­ного перес­каза ОС Minix, раз­работ­ка велась под ней же, и работа­ли пер­вые вер­сии Linux на фай­ловой сис­теме Minix. Называ­лась та незамыс­ловато — MINIX file system — и, в свою оче­редь, была вдох­новле­на фай­ловой сис­темой UNIX — UFS. Но, пос­коль­ку сама Minix раз­рабаты­валась ско­рее в учеб­ных целях, ее фай­ловая сис­тема не обла­дала широки­ми воз­можнос­тями. Нап­ример, раз­мер раз­дела не мог пре­вышать 64 Мбайт, а мак­сималь­ная дли­на име­ни фай­ла — 14 или 30 сим­волов в зависи­мос­ти от вер­сии. Что­бы пре­одо­леть такие огра­ниче­ния, начали раз­рабаты­вать собс­твен­ную ФС для Linux.

Немного об истоках

Но­вая фай­ловая сис­тема рас­ширяла воз­можнос­ти MINIXfs, за что, видимо, и получи­ла наз­вание extended filesystem. Пер­вая реали­зация рас­ширен­ной фай­ловой сис­темы, ext fs, уви­дела свет в 1992 году в ядре Linux вер­сии 0.96c. Теперь при­вер­женцы Linux были огра­ниче­ны дву­мя гигабай­тами для раз­дела, а фай­лы мог­ли иметь имя дли­ной до 255 сим­волов. Тем не менее эта ФС была все еще срав­нитель­но прос­та, поэто­му даль­нейшее ее раз­витие не зас­тавило себя дол­го ждать. При­мер­но в это же вре­мя, кста­ти, в Linux появил­ся такой уро­вень абс­трак­ции, как вир­туаль­ная фай­ловая сис­тема (VFS), облегча­ющий добав­ление под­дер­жки новых ФС в ядро.

С появ­лени­ем через пару лет ext2 мак­сималь­ные раз­меры фай­ла и фай­ловой сис­темы воз­росли до 16 Гбайт и 2 Тбайт соот­ветс­твен­но (при раз­мере бло­ка 1 Кбайт). Часть бло­ков (обыч­но 5%) теперь резер­вирова­лась под рут, не поз­воляя обыч­ным поль­зовате­лям запол­нить весь раз­дел без остатка. Тог­да эта ФС ста­ла прак­тичес­ки стан­дартом де‑фак­то на линук­сах, а ее реали­зации, говорят, были и под NT.

Поколение ext3

Третья рас­ширен­ная фай­ловая сис­тема (Third extended file system, ext3) появи­лась поч­ти двад­цать лет назад в одной из вер­сий Linux 2.4.14. Она во мно­гом напоми­нает свою пред­шес­твен­ницу, ext2, но отли­чает­ся под­дер­жкой жур­налиро­вания (в тер­миноло­гии NTFS — тран­закций). В отли­чие от ext2fs, она нам­ного береж­нее отно­сит­ся к мас­сиву катало­гов, хотя, как мы уви­дим чуть далее, нам это не силь­но поможет.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Источник

Экстенты, файлы, суперблоки. Как работают файловые системы ext3 и ext4 и как в них восстанавливать данные

В 2006 году выш­ла в свет кни­га Кри­са Кас­пер­ски «Вос­ста­нов­ление дан­ных», которая быс­тро ста­ла бес­тсел­лером. Сей­час эта кни­га готовит­ся к пере­изда­нию. Мы пуб­лику­ем отры­вок из этой кни­ги, пос­вящен­ный вос­ста­нов­лению дан­ных в фай­ловых сис­темах ext.

Оши­боч­ное уда­ление фай­лов в *NIX — это дос­таточ­но рас­простра­нен­ное явле­ние, навер­ное, даже более час­тое, чем в мире Microsoft. Под Windows боль­шинс­тво фай­ловых опе­раций выпол­няет­ся вруч­ную с помощью про­вод­ника или дру­гих инте­рак­тивных средств типа FAR или Total Commander. Инте­рак­тивные сре­ды есть и в Linux (KDE, GNOME, XFCE…), но немалая часть фанатов Linux — пок­лонни­ки коман­дной стро­ки. Коман­дная же стро­ка — это регуляр­ные выраже­ния и скрип­ты, то есть авто­мати­зиро­ван­ные средс­тва управле­ния — мощ­ные, удоб­ные и, при неп­равиль­ном исполь­зовании, раз­рушитель­ные. Малей­шая неб­режность — и можешь нав­сегда поп­рощать­ся со сво­ими фай­лами!

Пе­реф­разируя Бул­гакова, мож­но ска­зать: мало того что файл смер­тен, так он еще и вне­зап­но смер­тен! Беда никог­да не пре­дуп­режда­ет о сво­ем при­ходе, и адми­нис­тра­тору при­ходит­ся быть пос­тоян­но начеку. Нес­коль­ко секунд назад все было хорошо: цве­ла вес­на, вин­честер ожив­ленно стре­котал все­ми сво­ими голов­ками, адми­нис­тра­тор отхле­бывал кофе из чер­ной круж­ки с над­писью root, как вдруг сот­ни гигабайт цен­ней­ших дан­ных вне­зап­но раз­летелись на мел­кие осколки. Все силы бро­шены на раз­гре­бание завалов и спа­сение всех, кого еще мож­но спас­ти.

Дос­тупность исходных тек­стов драй­вера фай­ловой сис­темы зна­читель­но упро­щает иссле­дова­ние ее внут­ренней струк­туры, которая, кста­ти говоря, очень прос­та. Поэто­му вос­ста­нов­ление дан­ных на раз­делах ext2/3/4 — задача три­виаль­ная.

ЗНАКОМЬТЕСЬ! СЕМЕЙСТВО РАСШИРЕННЫХ ФАЙЛОВЫХ СИСТЕМ

Из­началь­но Linux был чем‑то вро­де воль­ного перес­каза ОС Minix, раз­работ­ка велась под ней же, и работа­ли пер­вые вер­сии Linux на фай­ловой сис­теме Minix. Называ­лась та незамыс­ловато — MINIX file system — и, в свою оче­редь, была вдох­новле­на фай­ловой сис­темой UNIX — UFS. Но, пос­коль­ку сама Minix раз­рабаты­валась ско­рее в учеб­ных целях, ее фай­ловая сис­тема не обла­дала широки­ми воз­можнос­тями. Нап­ример, раз­мер раз­дела не мог пре­вышать 64 Мбайт, а мак­сималь­ная дли­на име­ни фай­ла — 14 или 30 сим­волов в зависи­мос­ти от вер­сии. Что­бы пре­одо­леть такие огра­ниче­ния, начали раз­рабаты­вать собс­твен­ную ФС для Linux.

Немного об истоках

Но­вая фай­ловая сис­тема рас­ширяла воз­можнос­ти MINIXfs, за что, видимо, и получи­ла наз­вание extended filesystem. Пер­вая реали­зация рас­ширен­ной фай­ловой сис­темы, ext fs, уви­дела свет в 1992 году в ядре Linux вер­сии 0.96c. Теперь при­вер­женцы Linux были огра­ниче­ны дву­мя гигабай­тами для раз­дела, а фай­лы мог­ли иметь имя дли­ной до 255 сим­волов. Тем не менее эта ФС была все еще срав­нитель­но прос­та, поэто­му даль­нейшее ее раз­витие не зас­тавило себя дол­го ждать. При­мер­но в это же вре­мя, кста­ти, в Linux появил­ся такой уро­вень абс­трак­ции, как вир­туаль­ная фай­ловая сис­тема (VFS), облегча­ющий добав­ление под­дер­жки новых ФС в ядро.

С появ­лени­ем через пару лет ext2 мак­сималь­ные раз­меры фай­ла и фай­ловой сис­темы воз­росли до 16 Гбайт и 2 Тбайт соот­ветс­твен­но (при раз­мере бло­ка 1 Кбайт). Часть бло­ков (обыч­но 5%) теперь резер­вирова­лась под рут, не поз­воляя обыч­ным поль­зовате­лям запол­нить весь раз­дел без остатка. Тог­да эта ФС ста­ла прак­тичес­ки стан­дартом де‑фак­то на линук­сах, а ее реали­зации, говорят, были и под NT.

Поколение ext3

Третья рас­ширен­ная фай­ловая сис­тема (Third extended file system, ext3) появи­лась поч­ти двад­цать лет назад в одной из вер­сий Linux 2.4.14. Она во мно­гом напоми­нает свою пред­шес­твен­ницу, ext2, но отли­чает­ся под­дер­жкой жур­налиро­вания (в тер­миноло­гии NTFS — тран­закций). В отли­чие от ext2fs, она нам­ного береж­нее отно­сит­ся к мас­сиву катало­гов, хотя, как мы уви­дим чуть далее, нам это не силь­но поможет.

Смещение Размер Описание

0 1 boot record ; Загрузочный сектор

(1024 bytes) 1 superblock ; Суперблок

2 1 group descriptors ; Дескриптор группы

3 1 block bitmap ; Карта свободных блоков

4 1 inode bitmap ; Карта свободных inode

5 214 inode table ; Массив inode (сведения о файлах)

219 7974 data blocks ; Блоки данных (файлы, каталоги)

819 1 superblock backup ; Копия суперблока

819 1 group descriptors backup ; Копия дескриптора группы

819 1 block bitmap ; Карта свободных блоков

819 1 inode bitmap ; Карта свободных inode

819 214 inode table ; Массив inode (сведения о файлах)

840 7974 data blocks ; Блоки данных (файлы, каталоги)

16385 1 block bitmap ; Карта свободных блоков

16386 1 inode bitmap ; Карта свободных inode

16387 214 inode table ; Массив inode (сведения о файлах)

16601 3879 data blocks ; Блоки данных (файлы, каталоги)

Вслед за супер­бло­ком идут дес­крип­торы групп ( group descriptors ) и кар­ты сво­бод­ного прос­транс­тва, они же битовые кар­ты ( block bitmap / inode bitmap ), которые не име­ют боль­шого прак­тичес­кого зна­чения для наших целей. Что же каса­ется таб­лицы инод, рас­положен­ной за ними, то она зас­лужива­ет более под­робно­го рас­смот­рения. В ext3fs (как и мно­гих дру­гих фай­ловых сис­темах из мира UNIX) так называ­емый индек­сный дес­крип­тор (inode, он же ино­да) игра­ет ту же самую роль, что и фай­ловая запись в NTFS. Здесь сос­редото­чена вся информа­ция о фай­ле, кро­ме его име­ни: тип фай­ла (обыч­ный файл, каталог, сим­воль­ная ссыл­ка и так далее), его логичес­кий и физичес­кий раз­мер, схе­ма раз­мещения на дис­ке, вре­мя соз­дания, модифи­кации, пос­ледне­го дос­тупа или уда­ления, пра­ва дос­тупа, а так­же ссыл­ки на файл. Фор­мат пред­став­ления ино­ды в ext3 выг­лядит так:

Смещение Размер Описание

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_osd1 ; Значение, зависящее от ОС

40 12×4 i_block ; Ссылки на первые 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 ; ACL файла

108 4 i_dir_acl ; ACL директории

112 4 i_faddr ; Положение последнего фрагмента

116 12 i_osd2 ; Структура, зависящая от ОС

По срав­нению с NTFS такая схе­ма хра­нения информа­ции о раз­мещении устро­ена нам­ного про­ще. Вмес­те с тем она и гораз­до «про­жор­ливее». С дру­гой сто­роны, ее несом­ненное дос­тоинс­тво по срав­нению с NTFS сос­тоит в том, что, пос­коль­ку все ссыл­ки хра­нят­ся в неупа­кован­ном виде, для каж­дого бло­ка фай­ла мож­но быс­тро най­ти соот­ветс­тву­ющий ему кос­венный блок, даже если inode пол­ностью раз­рушен!

Имя фай­ла, как уже ска­зано, в inode не хра­нит­ся. Ищи его внут­ри катало­гов, пред­став­ляющих собой мас­сив записей, фор­мат которо­го выг­лядит так:

Смещение Размер Описание

0 4 inode ; Ссылка на inode

4 2 rec_len ; Длина данной записи

6 1 name_len ; Длина имени файла

7 1 file_type ; Тип файла

При уда­лении фай­ла опе­раци­онная сис­тема находит соот­ветс­тву­ющую запись в катало­ге, обну­ляет поле inode и уве­личи­вает раз­мер пред­шес­тву­ющей записи (поле rec_len ) на величи­ну уда­ляемой записи. Таким обра­зом, пред­шес­тву­ющая запись «пог­лоща­ет» уда­лен­ную. Хотя имя фай­ла в течение некото­рого вре­мени оста­ется нет­ронутым, ссыл­ка на соот­ветс­тву­ющий ему индек­сный дес­крип­тор ( inode ) ока­зыва­ется унич­тожен­ной. Это соз­дает проб­лему, так как теперь при­дет­ся раз­бирать­ся, какому фай­лу при­над­лежит обна­ружен­ное имя.

От­дель­но сто­ит погово­рить о жур­нале фай­ловой сис­темы. Он гаран­тиру­ет целос­тность фай­ловой сис­темы в слу­чае неп­редви­ден­ных сбо­ев. При этом важ­но понимать, что целос­тность фай­ловой сис­темы сов­сем не озна­чает сох­ранность фай­лов!

Тем не менее наличие жур­нала игра­ет важ­ную роль при вос­ста­нов­лении дан­ных в ext3/4, пос­коль­ку информа­ция в нем зачас­тую помога­ет вос­ста­нав­ливать вза­имос­вязи эле­мен­тов катало­гов, инод и содер­жимого фай­лов (если она, конеч­но, еще не была затер­та новыми событи­ями фай­ловой сис­темы). Вот одна из при­чин, почему важ­но как мож­но ско­рее отмонти­ровать раз­дел со слу­чай­но уда­лен­ными фай­лами!

Жур­нал фай­ловой сис­темы ext3 (да и ext4) может работать в трех режимах, и от выбора будет зависеть как надеж­ность, так и про­изво­дитель­ность:

В самом индек­сном дес­крип­торе при уда­лении фай­ла тоже про­исхо­дят боль­шие изме­нения. Количес­тво ссы­лок ( i_links_count ) обну­ляет­ся и обновля­ется поле, хра­нящее вре­мя пос­ледне­го уда­ления ( i_dtime ). Все бло­ки, при­над­лежащие фай­лу, в кар­те сво­бод­ного прос­транс­тва ( block bitmap ) помеча­ются как неис­поль­зуемые, пос­ле чего дан­ный inode так­же осво­бож­дает­ся (обновля­ется inode bitmap ).

Что принесла нам ext4?

По­толок раз­делов ext3 сос­тавля­ет 16 Тбайт. И если обыч­ным поль­зовате­лям это огра­ниче­ние до лам­почки, то в кор­поратив­ных сег­ментах оно при­носит неудобс­тва. К тому же исполь­зование битовых карт на боль­ших раз­делах (начиная при­мер­но с 1 Тбайт) замет­но наг­ружа­ет ЦП. В резуль­тате при­мер­но в ядре вер­сии 2.6.19 появи­лась ext4fs. Она не так сов­мести­ма с ext3, как та сов­мести­ма с ext2, хотя ext3-раз­дел мож­но при­мон­тировать как ext4 и наобо­рот (но тог­да теря­ется смысл новов­ведений в пос­ледней ФС). Более того, раз­работ­чики пре­дус­мотре­ли воз­можность перехо­да с ext3 на ext4 без перефор­матиро­вания раз­дела.

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

Так­же в ext4 появил­ся механизм кон­троль­ных сумм жур­нала, гаран­тиру­ющий, что в фай­ловую сис­тему будут вне­сены кор­рек­тные изме­нения. Но, как и пред­шес­твен­ница, ext4 может работать вооб­ще без жур­нала, что нем­ного улуч­шает ее про­изво­дитель­ность, но неиз­бежно ухуд­шает надеж­ность фай­ловой сис­темы. Тем не менее дан­ный режим мож­но наз­вать более пред­почти­тель­ным для устрой­ств на осно­ве флеш‑памяти, пос­коль­ку очень час­тые изме­нения фай­ла жур­нала рас­ходу­ют ресурс яче­ек памяти.

В общем, казалось бы, с такими нов­шес­тва­ми наши дан­ные дол­жны зажить новой жизнью, не зная горес­тей! Но они по‑преж­нему могут про­пасть по мно­гочис­ленным при­чинам. Что же на это ска­жет нам ext4?

Струк­тура бло­ков ext4 не силь­но отли­чает­ся от име­ющей­ся в ext3. Нем­ного бо́льшие изме­нения ожи­дали струк­туру индек­сных дес­крип­торов. Во‑пер­вых, она при­обре­ла новые поля, ста­ла вдвое объ­емнее и занима­ет минимум 256 байт. Это поз­воля­ет ей хра­нить, нап­ример, мет­ки вре­мени с наносе­кун­дной точ­ностью (рань­ше была точ­ность до секун­ды), счет­чик изме­нений фай­ла (он дает кли­енту NFS воз­можность понять, изме­нил­ся ли файл на сто­роне сер­вера), а так­же вер­сию inode и ее кон­троль­ную сум­му.

По­лучить содер­жимое слу­жеб­ных дан­ных фай­ловой сис­темы в удо­бочи­таемом виде ты можешь с помощью коман­ды fsstat :

FILE SYSTEM INFORMATION

File System Type: Ext4

Compat Features: Journal, Ext Attributes, Resize Inode, Dir Index

InCompat Features: Filetype, Needs Recovery, Extents, Flexible Block Groups,

Read Only Compat Features: Sparse Super, Large File, Huge File, Extra Inode Size

Free Inodes: 1313879

Orphan Inodes: 1456398, 1456397, 1456396, 1456395, 1456394,

Block Groups Per Flex Group: 16

Free Blocks: 4295049

Уда­ление фай­ла в ext4 про­исхо­дит в целом так же, как и в ext3: в записи катало­га обну­ляет­ся поле inode и пред­шес­тву­ющая запись пог­лоща­ет уда­ляемую. В жур­нал при этом вно­сят­ся соот­ветс­тву­ющие записи. Так­же, бла­года­ря исполь­зованию экстен­тов, уда­ление боль­ших фай­лов в ext4 быс­трее, чем в ext3.

В ПОИСКАХ УТРАЧЕННЫХ ДАННЫХ

В пер­вую оче­редь обя­затель­но раз­монти­руй дис­ковый раз­дел или, на худой конец, перемон­тируй его в режим «толь­ко чте­ние». Лечение активных раз­делов зачас­тую лишь уве­личи­вает мас­шта­бы раз­рушений. Если вос­ста­нав­лива­емые фай­лы находят­ся на основном сис­темном раз­деле, у нас два пути — заг­рузить­ся с Live CD или под­клю­чить вос­ста­нав­лива­емый жес­ткий диск на Linux-машину вто­рым.

Особенности восстановления файлов в ext3

В ext3fs пол­ное вос­ста­нов­ление фай­лов невоз­можно, даже если эти фай­лы были толь­ко что уда­лены. В этом отно­шении дан­ная фай­ловая сис­тема про­игры­вает как FAT, так и NTFS. Как минимум — теря­ется имя фай­ла. Точ­нее говоря, как минимум теря­ется связь имен фай­лов с их содер­жимым. При уда­лении неболь­шого количес­тва хорошо извес­тных фай­лов эта проб­лема оста­ется реша­емой. Одна­ко ситу­ация серь­езно осложня­ется, если ты уда­лил нес­коль­ко слу­жеб­ных под­катало­гов, в которых никог­да рань­ше не заг­лядыва­ли.

В целом стра­тегия вос­ста­нов­ления выг­лядит приб­лизитель­но так: ска­ниру­ем таб­лицу индек­сных дес­крип­торов ( inode table ) и отби­раем все записи, чье поле i_links_count рав­но нулю. Сор­тиру­ем их по дате уда­ления, что­бы фай­лы, уда­лен­ные пос­ледни­ми, ока­зались в вер­хних позици­ях спис­ка. Как вари­ант, если ты пом­нишь при­мер­ное вре­мя уда­ления фай­ла, мож­но прос­то наложить филь­тр.

А что с ext4?

По сути, про­цесс вос­ста­нов­ления фай­лов (вер­нее, проб­лемы, пре­пятс­тву­ющие это­му) тот же, что и в ext3. Одна­ко лет этак десять назад появи­лась ути­лита с замеча­тель­ным наз­вани­ем ext4magic (которая, впро­чем, уме­ет работать и с раз­делами ext3). Она уже нес­коль­ко лет не обновля­лась, но и сами струк­туры ФС тоже по боль­шей час­ти сфор­мирова­лись дав­но.

Эта прог­рамма в отдель­ных слу­чаях спо­соб­на спас­ти не толь­ко фай­лы, но и их наз­вания вмес­те со все­ми атри­бута­ми! Важ­ную роль при вос­ста­нов­лении игра­ет сос­тояние жур­нала, которое и поз­воля­ет реконс­тру­иро­вать вза­имос­вязь фай­лов с опи­сыва­ющей их слу­жеб­ной информа­цией — эле­мен­тами катало­гов и индек­сны­ми дес­крип­торами. Естес­твен­но, чем мень­ше прош­ло вре­мени и сде­лано изме­нений в фай­ловой сис­теме с момен­та уда­ления фай­лов, тем боль­ше веро­ятность их успешно вос­ста­новить. Пос­ле слу­чай­ного уда­ления фай­ла сле­дует как мож­но быс­трее отмонти­ровать ФС и по воз­можнос­ти соз­дать образ вос­ста­нав­лива­емо­го раз­дела и работать уже с ним. Что ж, в этом деле без магии (и буб­на) никак!

Сле­дующая коман­да воз­вра­щает из небытия фай­лы, которые ути­лита соч­ла уда­лен­ными за пос­ледние 24 часа. По умол­чанию они сох­раня­ются в пап­ку RECOVERDIR в рабочем катало­ге.

WARNING

Не забывай, что вос­ста­нав­ливать фай­лы на сам вос­ста­нав­лива­емый раз­дел — очень пло­хая затея!

Бо­лее того, сей­час, ког­да Linux далеко не толь­ко «конс­трук­тор для гиков», ext4magic уже не единс­твен­ная тул­за, уме­ющая вос­ста­нав­ливать фай­лы на ext-раз­делах. Вооб­ще говоря, таким ути­литам мож­но пос­вятить отдель­ную статью, но на вся­кий слу­чай твои дра­гоцен­ные дан­ные могут спас­ти: DMDE, PhotoRec (от соз­дателей ути­литы testdisk ), The Sleuth Kit, foremost.

Так­же сущес­тву­ет ути­лита R-Studio, под­держи­вающая и вос­ста­нов­ление с раз­делов ext2/3/4. Есть вер­сия и под Linux, а еще — бес­плат­ный про­дукт под наз­вани­ем R-linux, работа­ющий исклю­читель­но с семей­ством рас­ширен­ных фай­ловых сис­тем. Вооб­ще говоря, часть из перечис­ленных прог­рамм вос­ста­нав­лива­ет фай­лы по их сиг­натурам из сырых обра­зов раз­делов. Они, счи­тай, не зависят от исполь­зуемой ФС, но в то же вре­мя не помогут вос­ста­новить име­на фай­лов и струк­туру катало­гов и малопо­лез­ны при фраг­мента­ции фай­лов.

ОН ВЫЖИВЕТ?

Фай­лам — жить! Даже если им слу­чилось попасть под горячую руку не на раз­деле NTFS. И чем мень­ше вре­мени прош­ло с момен­та неудач­ного уда­ления, тем боль­ше шан­сов на успешное вос­ста­нов­ление. Осо­бен­но если вов­ремя раз­монти­ровать раз­делы, вни­матель­но про­верять вво­димые коман­ды и вов­ремя делать резер­вные копии. Ты ведь сде­лал бэкап?

Источник