воскресенье, 17 мая 2009 г.

Восстановления данных с лазерных дисков

…такой объем информации можно уничтожить в один миг разве что динамитом, потому что существуют дублирующие  системы и у скорости обработки есть предел

Джон Варли "Нажмите ENTER"

Заявляя о своей поддержке многосессионных дисков, операционные системы Windows 9x и Windows NT (вплоть до W2K включительно) тактично умалчивают о том, что поддерживают их лишь частично. Каждая сессия – это вполне самостоятельный том (в терминологии Windows – "логический диск"), имеющий свою собственную файловую систему и свои собственные файлы. Благодаря сквозной нумерации секторов лазерного диска, файловая система одной сессии может ссылаться на файлы, физически расположенные в любой другой сессии. Для того, чтобы с многосессионным диском было можно работать как с единым томом, файловая система последней сессии должна включать в себя содержимое файловых систем всех предыдущих сессий. Если этого не сделать, то при просмотре диска штатными средствами Windows, оглавления остальных сессий окажутся потерянными, поскольку Windows монтирует лишь последнюю сессию диска, а все прочие – игнорирует. Программы "прожига" CDR/RW по умолчанию добавляют содержимое файловой системы предыдущей сессии к последующей, однако это еще не означает, что последняя сессия диска всегда содержит в себе все то, что имеют предыдущие.

Рассмотрим например, как осуществляется удаление файлов с CD-R/RW. Нет, это не опечатка! Содержимое дисков CD-R, несмотря на физическую невозможность их перезаписи, в принципе все же уничтожаемо. Для имитации удаления файла, программы записи на CD просто не включают ссылку на уничтожаемый файл в файловую систему последней сессии. И хотя "удаленный" файл все еще присутствует на диске, "отъедая" часть дискового пространства, при просмотре содержимого диска из-под Windows он уже не отображается в каталоге. Какой же тогда смысл несет в себе удаление файлов с CD-R, если свободная емкость диска при этом не увеличивается, а даже уменьшается?! – удивленно спросит иной читатель. На самом же деле, смысл этой операции (если, его вообще можно назвать "смыслом") заключен исключительно в сокрытии "удаляемых" файлов от простых пользователей. Раз удаленные файлы не видны при просмотре содержимого диска штатными средствами, то неквалифицированному пользователю они формально недоступны. Подчеркиваю: для штатных средств операционной системы Windows – недоступны, но те же "Маки" позволяют монтировать любую сессию диска на отдельный том, благодаря чему при просмотре многосессионных дисков под "Маками" все удаленные файлы сразу же "всплывают".

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

Поэтому, записывая на диск информацию, предназначенную для передачи постороннему лицу, ни в коем случае не используйте для этой цели, болванки, содержащие конфиденциальные данные. "Удаление" ранее записанных на болванку данных на самом деле не уничтожает их!

Просматривая содержимое лазерного диска, полученного от приятеля (купленного на радио-рынке, вытащенного из мусорной корзины) имеет смысл попытаться заглянуть внутрь предыдущих сессий на предмет поиска скрытой информации. Как показывает практика, очень часто там обнаруживается много интересного. Так же, вам может потребоваться восстановить ошибочного удаленный файл со своего собственного диска, а то и воскресить всю пришибленную сессию целиком (некоторые программы записи на CD позволяют пользователю выбирать: следует ли при создании новой сессии добавлять в нее файловую систему предыдущей или же в новую сессию следует включать только новые файлы. Неверный выбор настроек приводит к утрате содержимого всех предыдущих сессий, но к счастью, эта утрата обратима).

Для восстановления удаленных файлов можно воспользоваться любой программой, умеющий извлекать содержимое выбранной сессии диска и записывать его в ISO-образ. Пусть для определенности это будет Roxio Easy CD Creator. Позволив приводу "заглотить" восстанавливаемый диск, в меню "CD" выбираем пункт "CD Information" и после непродолжительного ерзанья головки привода на экране отображается диалоговое окно.

Как мы и видим, перед нами представлен перечень всех сессий, имеющихся на диске с указанием номеров, стартовых адресов (в секторах) и длин (в мегабайтах). Давайте попробуем определить, имеются ли на диске скрытые файлы или нет. Используя команду "dir", выведем директорию диска и запомним суммарный размер всех файлов, которые только "видит" операционная система:

 

KPNC$G:\>dir

 Том в устройстве G имеет метку 030710_1433

 Серийный номер тома: 4DD0-BB09

 Содержимое папки G:\

28.05.2003  05:57            6 283 745 phck31.drf.zip

03.06.2003  05:39            8 085 410 phck31.Вт 03.06.2003.zip

04.06.2003  16:45            7 898 149 phck31.Ср 04.06.2003.zip

05.06.2003  06:06            6 718 926 phck31.Чт 05.06.2003.zip

03.07.2003  15:51           10 612 230 phck31.Чт 03.07.2003.zip

05.07.2003  06:37            8 946 860 phck31.Сб 05.07.2003.zip

08.07.2003  12:51            9 009 642 phck31.Вт 08.07.2003.zip

09.07.2003  06:21            9 138 651 phck31.Ср 09.07.2003.zip

10.07.2003  14:32            9 388 543 phck31.Чт 10.07.2003.zip

               9 файлов     76 082 156 байт

               1 папок               0 байт свободно

Листинг 1 вывод содержимого диска на экран, на самом деле коварная Windows выводит содержимое одной лишь последней сессии диска. Что содержат все остальные – не известно. Во всяком случае – пока неизвестно

Ага, совокупный объем девяти файлов, доступных для операционной системы, составляет всего 72 мегабайта (76.082.156 байт), а совокупный объем всех сессий диска – 47,66 + 6,50 + 8,21 + 8,04 + 6,91 + 10,62 + 9,04 + 9,10 + 9,22 + 9,46 == 124,76 МБ, что на 52 МБ длиннее! (примечание: поле "Write Sector", содержащее длину записанной области диска и равное в данном случае 255 Мб, для наших целей абсолютно бесполезно, поскольку в записанную область диска входят не только полезные данные, но и служебные области каждой сессии, в результате чего полная емкость диска всегда меньше его эффективной емкости даже если на нем нет никаких удаленных файлов).

В какой именно сессии содержаться удаленные файлы сказать невозможно, – они могут присутствовать в любой из них (или даже в нескольких сессиях сразу). Поэтому, в общем случае все имеющиеся сессии должны просматриваться последовательно. Однако, иногда удается найти более короткие пути. Применительно к рассматриваемому нами примеру: давайте попробуем оттолкнуться от того факта, что количество имеющихся на диске сессий на единицу больше числа выведенных командой dir файлов, причем, размеры девяти последних секций практически совпадают с размерами соответствующих им файлов. Первая же сессия диска, имеющая размер 48 МБ, не соответствует ни одному из видимых файлов. Что же она тогда содержит? А вот сейчас смонтируем эту сессию на отдельный дисковый том и посмотрим! К сожалению, штатные средства Windows не позволяют осуществлять такое монтирование непосредственно и потому приходится идти обходным путем, записывая выбранную сессию в ISO-образ с последующим копированием последнего на чистый CD-R/CD-RW диск. Естественно, CD-RW диски более практичны для таких экспериментов, поскольку их можно использовать многократно. Еще удобнее Alcohol 120%, динамически монтирующий ISO-образы на виртуальный CD-ROM, и тем самым экономящий кучу времени (но, к сожалению, он не предоставляет возможности выбора сохраняемых сессий и всегда помещает в создаваемый им образ содержимое всего диска целиком, поэтому одного лишь Алкоголика для наших экспериментов будет более чем недостаточно).

Возвращаясь к нашим баранам (простите, к Roxio Easy CD Creator), дважды щелкнем мышем по строке "Session 1" или, предварительно выделив ее курсором, нажмем на кнопку "Read Track". 

Поле "Имя файла", как и следует из его названия, задает имя образа (по умолчанию "Track"), а "Тип файла" – формат. Каким либо образом "колдовать" над ним бесполезно, поскольку других форматов бесплатная версия программы все равно не поддерживает и возможность их выбора (точнее видимость возможности выбора) предоставляется пользователю исключительно из соображений этикета и/или вежливости.

А вот настройки, обведенные рамкой "Read Data Track Settings", намного более интересны. Окно редактирования "Start Block" содержит LBA-адрес первого сектора выбранной сессии, а "Length in Block" – длину сессии в секторах и по умолчанию сюда подставляется информация, подчеркнутая из TOC'а. При условии, что TOC не был умышленно искажен с целью защиты диска от копирования, этим данным можно верить. Однако, как мы увидим в дальнейшем искажение TOC'а не редкость и с ним довольно часто приходится сталкиваться на практике (впрочем, возможности Easy CD Creator'a по восстановлению треков с искаженными адресами даже более чем ограничены, т. к. он слишком щепетильно проверяет "правильность" начального и конечного адресов и, если TOC говорит, что начальный адрес больше конечного, то Easy CD Creator будет свято верить TOC'у, причем настолько свято, что все попытки убедить его в обратном заранее обречены на провал, так что для работы с защитами лучше подыскать другую программу – поумнее).

Поле "Block Size" содержит размер пользовательской части сектора в байтах. Свобода выбора здесь представлена чисто символически, – все равно изменить это значение вы не сможете (да и нужно ли его изменять? ведь "сырых" секторов Easy CD Creator все равно не поддерживает, а размер пользовательской части сектора однозначно определяется типом самого сектора и его изменение – бессмысленно).

Короче говоря, оставив все установки в состоянии, предлагаемом по умолчанию, нажимаем кнопочку "сохранить" и некоторое время ждем, пока выбранная нами сессия копируется в ISO-файл. Когда же процесс "трансплантации" будет закончен, сформированный образ можно "закатать" на новую болванку тем же Easy CD Creator'ом (для в меню "File" необходимо выбрать пункт "Record CD from CD image", указав в типе файлов "ISO Image File"), либо запустить "Алкоголика" и смонтировать образ на виртуальный диск.

Так или иначе, доступ к удаленным файлам будет получен и вы сможете делать с ними все, что хотите (внимание! при просмотре содержимого "сграбленной" сессии всегда учитывайте что: во-первых, файлы, физически принадлежащие другим сессиях, из данной сессии окажутся недоступными, в то время как ссылки на них здесь могут изобиловать. При обращении к реально несуществующему файлу будет выдаваться либо мусор, либо сообщение об ошибке. Как альтернативный вариант – операционная система может просто зависнуть. Если это произошло, просто нажмите кнопку выброса диска. Windows тут же выйдет из ступора и радостно завопит "устройство не готово". Во-вторых, в силу сквозной адресации секторов, каждая "сграбленная" сессия должна записывается на тоже самое место диска, на котором она была ранее, в противном случае все ссылки на стартовые адреса файлов внутри этой сессии окажутся недействительными. Требуемый результат обычно достигается изменением стартового адреса первого трека. О том, как это сделать, рассказывается в следующей части статьи, посвященной восстановлению информации с очищенных CD-RW дисков).

четверг, 14 мая 2009 г.

Восстановление удаленных файлов под Linux: заключение

Доступность исходных текстов драйвера файловой системы значительно упрощает исследование ее внутренней структуры, которая кстати говоря очень проста и восстановление данных на ext2fs/ext3fs – плевое дело. Файловые системы UFS и FFS, работающие под Free BSD, устроены намного сложнее, к тому же достаточно скудно документированы. А ведь Free BSD занимает далеко не последнее место в мире UNIX-совместимых операционных систем и разрушения данных даже в масштабах небольшого городка происходят сплошь и рядом. К счастью, в подавляющем большинстве случаев информацию можно полностью восстановить, но об этом — в следующий раз.

 что читать

q       Design and Implementation of the Second Extended File system

o        подробное описание файловой системы ext2fs от самих разработчиков проекта. на английском языке. http://e2fsprogs.sourceforge.net/ext2intro.html;

q       Linux Ext2fs Undeletion mini-HOWTO

o        краткая, но доходчивая инструкция по восстановлению удаленных файлов на ext2fs разделах. на английском языке. http://www.praeclarus.demon.co.uk/tech/e2-undel/howto.txt;

q       Ext2fs Undeletion of Directory Structures mini-HOWTO

o        краткое руководство по восстановлению удаленных директорий на ext2fs разделах. на английском языке: http://www.faqs.org/docs/Linux-mini/Ext2fs-Undeletion-Dir-Struct.html;

q       HOWTO-undelete

o        еще одно руководство по восстановлению удаленных файлов на ext2fs разделах с помощью редактора lde. на английском языке. http://lde.sourceforge.net/UNERASE.txt;

Восстановление удаленных файлов под Linux: техника восстановления удаленных файлов

В ext2fs полное восстановление даже только что удаленных файлов, невозможно. В этом смысле она проигрывает как FAT, так и NTFS. Как минимум теряется имя файла. Точнее говоря, теряется связь имен файлов с их содержимым. При удалении небольшого количества хорошо известных файлов это еще терпимо (имена-то ведь сохранились!), но что делать, если вы удалили несколько служебных подкаталогов, в которых никогда ранее не заглядывали?

Достаточно часто inod'ы назначаются в том же порядке, в котором создаются записи в таблице директорий, к тому же существует такая штука как "расширения" (.c, .gz, .mpg и т. д.), так количество возможных комбинаций соответствий чаще всего бывает относительно небольшим. Тем не менее, восстановить удаленный корневой каталог в автоматическом режиме никому не удастся (а вот NTFS с этим справляется без труда).

В общем случае, стратегия восстановления выглядит приблизительно так: сканируем таблицу inode и отбираем все записи, чье поле i_links_count равно нулю. Сортируем их по дате удаления, чтобы файлы, удаленные последними, оказались наверху списка. Как вариант, можно просто наложить фильтр (мы ведь помним примерное время удаления, не правда ли?). Если соответствующие inod'ы еще не затерты вновь создаваемыми файлами, извлекаем список прямых/косвенных блоков и записываем их в дамп, корректируя его размер с учетом "логического" размера файла, за которое отвечает поле i_size.

восстановление при помощи lde

Открываем редактируемый раздел или его файловую копию: "lde my_dump" или "lde /dev/sdb1". Редактор автоматически определяет тип файловой системы (в данном случае ext2fs) и предлагает нажать any key для продолжения. Нажимаем! Редактор автоматически переключается в режим отображения супер-блока, и предлагает нажать <I> для перехода в режим inode и <B> для перехода в блочный режим (block-mode). Жмем <I> и оказываемся в первой inod'e, описывающей корневой каталог. <Page Dowd> перемещает нас к следующей inod'e, а <Page Up> к предыдущей. Пролистываем inod'ы вниз, обращая внимание на поле LINKS. У удаленных файлов оно равно нулю и тогда "DELETION TIME" содержит время последнего удаления (мы ведь помним его, правда?). Обнаружив подходящую inod'у, перемещаем курсор к первому блоку в списке DIRECT BLOCKS (где он должен находиться по умолчанию) и нажимаем <F2>. В появившемся меню выбираем пункт "Block mode, viewing block under cursor" (или сразу нажимаем горячу клавишу <Shift-B>). Редактор перемещается на первый блок удаленного файла. Просматривая его содержимое в hex-режиме, пытаемся определить он ли это или нет. Чтобы возвратиться к просмотру следующей inod'ы, нажимаем <I>, чтобы восстановить файл — <Shift-R>, затем еще раз <R> и имя файла-дампа для восстановления.

Можно восстанавливать файлы и по их содержимому. Допустим, нам известно, что удаленный файл содержит строку "hello, world". Нажимаем и затем (Search all block). Этим мы заставляем редактор искать ссылки на все блоки, в том числе и удаленные. Как вариант, можно запустить редактор с ключом "--all". Но так или иначе, мы нажимаем <B>, и когда редактор перейдет в block-mode, давим и вводим ASCII-строку для поиска. Находим нужный блок. Прокручивая его вверх-вниз, убеждаемся, что он действительно принадлежит тому самому файлу. Если это так, нажимаем <Ctrl>+<R>, заставляя редактор просматривать все inod'ы, содержащие ссылку на этот блок. Номер текущей найденной inod'ы отображается внизу экрана. (Именно что внизу! Вверху отображается номер последней просмотренной inod'ы в режиме inod'e). Переходим в режим inod'е по клавише <I>, нажимаем <#> и вводим номер inod'ы, которую хотим просмотреть. Если дата удаления более или менее соответствует действительности, нажимаем <Shift-R>/<R> для сброса файла на диск. Если нет — возвращаемся в block-mode и продолжаем поиск.

В сложных случаях, когда список прямых и/или косвенных блоков разрушен, восстанавливаемый файл приходится собирать буквально по кусочкам, основываясь на его внутреннем содержимом и частично — на стратегии выделения свободного пространства файловой системой. В этом нам поможет клавиша <w>  — дописать текущий блок к файлу-дампу. Просто перебираем все свободные блоки один за другим (редактор помечает их строкой NOT USED), и обнаружив подходящий, дописываем в файл. Конечно, сильно фрагментированный бинарник так не восстановить, но вот листинг программы — можно вполне.

Вывод — ручное восстановление файлов с помощью lde крайне непроизводительно и трудоемко, зато наиболее "прозрачно" и надежно. А вот восстанавливать оригинальные имена лучше всего при помощи debugfs.

восстановление при помощи debugfs

Загружаем в отладчик редактируемый раздел или его копию, "debugfs my_dump" или "debugfs /dev/sdb1". Если мы планируем осуществлять запись на диск, необходимо указать ключ "–w" ("debugfs w my_dump" или "debugfs /dev/sdb1".

Чтобы просмотреть список удаленных файлов даем команду "lsdel" (или "lsdel t_sec", где t_sec количество секунд, прошедшее со момента удаления файла). Экран заполняется список удаленных файлов. Естественно без имен. Файлы, удаленные более, чем t_sec секунд назад (если sec задан) в этот список не попадают.

Команда "cat <N>", выводит содержимое текстового файла на терминал, где <N>, номер inod'ы, заключенный в угловые кавычки. При выводе двоичных файлов на экране творится черт знает что, и такие файлы должны сбрасываться в дамп командой "dump <N> new_file_name", где new_file_name новое имя файла (с путем), под которым он будет записан в нативную (native) файловую систему, т. е. ту файловую систему из-под которой был запущен debugfs. Файловая система восстанавливаемого раздела при этом остается неприкосновенной. Другими словами, наличие ключа "--w" для этого не требуется.

При желании можно восстановить файл непосредственно на самой восстанавливаемой файловой системе (что особенно удобно при восстановлении больших файлов). В этом нам поможет команда "undel <Nundel_file_name", где undel_file_name — имя, которое будет присвоено файлу после восстановления. Внимание! Когда будете это делать, помните, что команда undel крайне агрессивна и деструктивна по своей природе. Она затирает первую свободную запись в таблице директорий, делая восстановление оригинальных имен невозможным!

Команда "stat <N>" отображает содержимое inod'ы в удобочитаемом виде, а команда "mi <N>" позволяет редактировать их по своему усмотрению. Для ручного восстановления файла (которого не пожелаешь и врагу) мы должны установить счетчик ссылок (link count) в единицу, а время удаления (deletion time), наоборот, сбросит в нуль. Затем отдать команду "seti <N>", помечающую данную inod'у как используемую, и для каждого из блоков файла выполнить "setb X", где – номер блока (перечень блоков, занимаемых файлов, можно подсмотреть командой stat, причем, в отличии от lde она отображает не только непосредственные, но и косвенные блоки, что несравненно удобнее). Остается только дать файлу имя, что осуществляется путем создания каталожной ссылки (directory link), а делает это команда "ln <N> undel_file_name", где undel_file_name – имя, которое будет дано файлу после восстановления, при необходимости с путем. (Внимание! создание каталожных ссылок необратимо затирает оригинальные имена удаленных файлов). После этого полезно дать команду "dirty", чтобы файловая система была автоматически проверка при следующей загрузке, или выйти из отладчика и вручную запустить fsck с ключом "–f", форсирующим проверку.

Теперь перейдем к восстановлению оригинального имени. Рассмотрим простейший случай, когда директория, содержащая удаленный файл (так же называемая материнской директорией) все еще цела. Даем команду "stat dir_name" и запоминаем номер inode, который нам сообщат. Говорим отладчику "dump <INODE> dir_file", где INODE – номер сообщенной inod'ы, dir_file имя файла нативной файловой системы, в которую будет записан дамп. Загружаем полученный дамп в hex-редактор и просматриваем его содержимое в "сыром" виде. Все имена будет там. При желании можно написать утилиту-фильтр, выводящую только удаленные имена. На Perl'е это не замет и десяти минут.

А как быть если материнская директория тоже удалена? Тогда она и будет помечена удаленной! Выводим список удаленных inod'е, отбираем из них директории, формируем перечень принадлежащих им блоков и дампим в файл, просматриваемый вручную или с помощью утилиты-фильтра. Как уже отмечалось, порядок расположения файлов в inod'е очень часто совпадает с порядком расположения файлов в директории, поэтому восстановление оригинальных имен в четырех из пяти случаев проходит на ура.

При тяжких разрушениях, когда восстанавливаемый файл приходится собирать по кусочкам, помогает команда "dump_unused", выводящая на терминал в все неиспользуемые блоки. Имеет смысл перенаправить вывод в файл, запустить hexedit и покопаться в этой куче хлама — это по крайней мере проще, чем лазить по всему диску (на дисках, заполненных более чем на три четверти, этот трюк сокращает массу времени).

Вывод: debugfs в значительной мере автоматизирует восстановление удаленных файлов (впрочем, до полного комфорта ему далеко), однако, восстановить файл с разрушенным inode он не способен и без lde здесь не обходится.

 

восстановление при помощи R-Studio

Утилита R-Studio for NTFS, уже рассмотренная нами в предыдущих номерах журнала, вопреки своему названию, поддерживает не только NTFS, но и ext2fs/ext3fs. С точки зрения неквалифицированных пользователей это хорошее средство для автоматического восстановления удаленных файлов: интуитивно-понятный интерфейс, простое управление и прочие прелести прогресса. Файлы восстанавливаются несколькими щелчками. Правда без и имен и без каких-либо гарантий, что они вообще восстановятся. Ручное восстановление не поддерживается. Файлы с разрушенной inode не восстанавливаются, хотя под ext2fs, в отличии от NTFS это достаточно просто сделать!

В общем, для профессионального использования R-Studio катастрофически не подходит.

восстановление удаленных файлов на ext3fs

Файловая система ext3fs это ext2fs с поддержкой журналирования (в терминологии NTFS – транзакций). В отличие от ext2fs она намного бережнее относится к массиву директорий и при удалении файла, ссылка на inode уже не уничтожается, что упрощает автоматическое восстановление оригинальных имен. Однако, поводов для радости у нас нет никаких, поскольку в ext3fs перед удалением файла список принадлежащих ему блоков тщательно вычищается. Как следствие — восстановление становится невозможно. Ну… практически невозможно. Нефрагментированные файлы с более или менее осмысленным содержимым (например, исходные тексты программ) еще можно собрать по частям, но и времени на это уйдет… К счастью, косвенные блоки не очищаются, а, значит, мы теряем лишь первые 12 * BLOCL_SIZE байт каждого файла. На типичном 10 Гбайтном разделе BLOCK_SIZE обычно равен 4- или 8 Кбайтам, т. е. реальные потери составляют менее 100 Кбайт. По современным понятиям сущие пустяки! Конечно, без этих 100 Кбайт большинство файлов просто не запустятся, однако, недостающие 12 блоков найти на диске вполне реально. Если повезет, они окажутся расположенными в одном-двух непрерывных отрезках. Даже на сильно фрагментированных разделах, непрерывные отрезки из 6-12 блоков достаточно часто встречаются.

Как мы будем действовать? Необходимо найти хотя бы один блок, гарантированно принадлежащий файлу и при этом расположенных за границей в 100 Кбайт от его начала. Это может быть текстовая строка, копирайт фирмы да все что угодно! Короче, нам нужен номер блока. Пусть для определенности он будет равен 0x1234. Записываем его в обратном порядке так, чтобы младший байт располагался по меньшему адресу и выполняем поиск 34120000h — именно это число будет присутствовать в косвенном блоке. Отличить косвенный блок от всех остальных блоков (например, блоков, принадлежащих файлам данных) очень легко — он представляет собой массив 32-битных номеров блоков более или менее монотонно возрастающих. Дважды и трижды косвенные блоки отыскиваются по аналогичной схеме.

Проблема в том, что одни и те же блоки в разное время могли принадлежать различным файлам, а, значит, и различным косвенным блокам. Как разобраться какой из них правильный? Да очень просто! Если хотя бы одна из ссылок косвенного блока указывает на уже занятый блок, данный косвенный блок принадлежит давно удаленному файлу и нам совсем не интересен.

Кстати говоря, debugfs довольно криво поддерживает ext3fs. В частности, команда lsdel всегда показывает ноль удаленных файлов, даже если грохнуть ### удалить весь раздел. Так что вопрос выбора файловой системы отнюдь не так прост, каким его пытаются представить книги "LINUX для начинающих", а преимущества ext3fs на рабочих станциях и домашних компьютерах далеко небесспорны и неочевидны. Поддержка транзакций реально требуется лишь серверам (да и то не всем), а вот невозможность восстановления ошибочного удаленных файлов зачастую приносит намного большие убытки, чем устойчивость файловой к внезапным отказам питания.