Война миров: ext2 vs ext3

Крис Касперски ака мыщъх

Хакер, номер #086, стр. 086-108-2

Многие сравнивают ext2 с FAT, а ext3 с NTFS, но это неверно. По своей архитектуре ext2 гораздо ближе к NTFS, чем к FAT. Грубо говоря, ext2 - это NTFS без транзакций. За счет высокой степени избыточности (большого количества дублирующих друг друга структур), ext2 весьма стойко переносит сбои, и поэтому за ее целостность можно особо не волноваться. После внезапного выключения питания она не упадет. Поддержка транзакций в ext3 увеличивает надежность хранения данных, но не столь радикально, как некоторые пытаются доказать. При выборе режима «журналировать только метаданные» (data=writeback) все открытые на запись данные в момент исчезновения питания могут обнуляться или заполняться мусором. В режиме «журналировать все» (data=journal) все данные сначала пишутся в журнал и только затем переносятся в файл. Это значительно снижает производительность, но зато гарантирует непротиворечивость состояния данных и метаданных: файл либо записывается полностью, либо не записывается вообще. То есть потеря информации при внезапном исчезновении питания или перезагрузке все-таки возможна.

А вот восстанавливать данные на ext3 значительно труднее, чем на ext2, поскольку перед удалением файла список принадлежащих ему блоков тщательно вычищается, и undelete сделать уже невозможно. Причем это не баг, а «так задумано». На портале www.opennet.ru лежит FAQ по файловой системе ext3 (www.opennet.ru/base/faq/ext3_faq.txt.html), которое со ссылкой на Andreas Dilger'а (одного из разработчиков) говорит следующее: «После падения для проверки возможности безопасного продолжения разлинковки (unlink) файловая система ext3 обнуляет указатели на блоки в inode'ах, а ext2 просто помечает эти блоки как неиспользуемые, inode'ы - как удаленные, оставляя указатели нетронутыми. Единственное, что вам остается делать - вызывать grep для нахождения частей удаленных файлов и надеяться на лучшее».

Но все не так безнадежно. Да, указатели на DIRECT блоки гибнут безвозвратно, однако содержимое блоком косвенной адресации остается нетронутым, и хвост файла восстанавливается элементарно. Собирать по кускам приходится только его начало. Подробнее об этом можно прочитать в моей книге «Техника восстановления данных» (название рабочее), которая выйдет в ближайшее время, ну а пока доступна только «облегченная» версия, живущая на мыщъхином ftp.

Другая серьезная проблема - целостность журнала и агрессивный характер fsck, неадекватным образом реагирующий на некоторые виды повреждений. В последнее время появилось множество сообщений о некачественных SATA-контроллерах, приводящих к различным сбоям, затрагивающим журнал и метаданные. Основная структура тома остается практически неповрежденной (так, маленькая трещинка), и ручным восстановлением его еще можно спасти, но запуск fsck грохает раздел окончательно, причем ext3 страдает намного сильнее, чем ext2. Вероятно, так происходит потому, что в журнале оказывается мусор, а fsck пытается его интерпретировать «правильным» образом, вот и... Конечно, поклонники ext3 могут сказать, что нечего ее гонять на кривом железе, нужно купить себе нормальный SCSI-контроллер и отказаться от АТА. Все это верно и совершенно правильно, но все-таки от сбоев железа никто не застрахован, поэтому при «обкатке» нового оборудования все-таки лучше использовать ext2 и только затем переходить на ext3. К тому же прежде чем позволять fsck лечить диск, настоятельно рекомендуется запустить дисковый редактор lde (сокращение от Linux Disk Editor) и посмотреть, что именно случилось с данными. Быть может, проще все восстановить вручную? Описание приемов работы с lde можно найти в заначках мыщъх'а, лежащих по адресу: kpnc.opennet.ru/recover.zip.