Листинг 8.11. Структура direct, отвечающая за хранение имен файлов и каталогов

struct direct {

/* 0x00 */ u_int32_t d_ino; /* Номер inode данной записи */

/* 0x04 */ u_int16_t d_reclen; /* Длина данной записи */

/* 0x06 */ u_int8_t d_type; /* Тип файла, см. ниже */

/* 0x07 */ u_int8_t d_namlen; /* Длина строки в d_name */

/* 0x08 */ char d_name[MAXNAMLEN + 1]; /* Имя с длиной <= MAXNAMLEN */

};

На этом описание файловой системы UFS можно считать законченным. Для ручного восстановления данных приведенной информации вполне достаточно.

На развалинах империи

При удалении файла на разделе UFS происходят следующие события (они перечислены в порядке расположения соответствующих структур в разделе и могут не совпадать с порядком их возникновения).

□ В суперблоке обновляется поле fs_time (время последнего доступа к разделу).

□ В суперблоке обновляется структура fs_cstotal (количество свободных inode и блоков данных в разделе).

□ В группе цилиндров обновляются карты занятых inode и блоков данных. Inode и все блоки данных удаляемого файла помечаются как освобожденные.

□ В inode родительского каталога обновляются поля времени последнего доступа и времени последней модификации.

□ В inode родительского каталога обновляется поле времени последнего изменения inode.

□ В inode удаляемого файла обнуляются поля di_mode (IFMT, права доступа), di_nlink (количество ссылок на файл) и di_size (размер файла).

□ В inode удаляемого файла затираются нулями поля di_db (массив указателей на 12 первых блоков файла) и di_ib (указатель на блок косвенной адресации).

□ В inode удаляемого файла обновляются поля времени последней модификации и последнего изменения inode, время последнего доступа при этом остается неизменным.

□ В inode удаляемого файла обновляется поле di_spare. В исходных текстах оно помечено как зарезервированное, но просмотр дампа показывает, что это не так. Судя по всему, здесь хранится нечто вроде последовательности обновления (update sequence), используемой для контроля целостности inode. Однако это только мое предположение.

□ В каталоге удаленного файла размер предшествующей структуры direct увеличивается на значение d_reclen, в результате чего она как бы "поглощает" имя удаляемого файла. Однако физического затирания имени не происходит. Во всяком случае оно затирается не сразу, а лишь в тот момент, когда в этом возникнет реальная необходимость.

Средства восстановления файлов

Обнаружив, что один или несколько файлов были непреднамеренного удалены, немедленно демонтируйте раздел и запустите дисковый редактор, работающий на секторном уровне. Например, можно воспользоваться вариантом уже описанного редактора lde, переписанным для BSD. К сожалению, в моей системе (4.5 BSD) он работает крайне нестабильно. Так, например, он не отображает основные структуры данных в удобочитаемом виде, хотя поддержка UFS в нем заявлена. При наличии достаточного количества свободного дискового пространства можно скопировать раздел в файл и натравить на него любой hex-редактор (например, BIEW). Как вариант, можно открыть непосредственно само устройство раздела (например, /dev/ad0s1a). Наконец, можно загрузить компьютер с загрузочного CD с Windows РЕ и воспользоваться любым Windows-редактором — от Microsoft Disk Probe до Runtime DiskExplorer. Можно загрузиться даже с загрузочной дискеты MS-DOS и запустить Norton Disk Editor (правда, Norton Disk Editor не поддерживает ни диски большого объема, ни устройства SCSI). Наконец, можно запустить KNOPPIX или любой дистрибутив Live Linux, ориентированный на восстановление данных. Правда, в большинстве "реанимационных" дистрибутивов, в частности, Frenzy 0.3, никакого дискового редактора вообще нет.

В общем, выбор средств восстановления достаточно широк.

Техника восстановления удаленных файлов

Начнем наше обсуждение на грустной ноте. Поскольку при удалении файла ссылки на 12 первых блоков и 3 блока косвенной адресации необратимо затираются, автоматическое восстановление данных принципиально невозможно. Найти удаленный файл можно только по его содержимому. Искать, естественно, необходимо в свободном пространстве. Вот тут-то нам и пригодятся карты, расположенные за концом описателя группы цилиндров.

Если нам повезет, и файл окажется нефрагментированным (а на разделах UFS, как уже отмечалось, фрагментация обычно отсутствует или крайне невелика), остальное будет делом техники. Достаточно выделить группу секторов и записать ее на диск. Здесь, как и во всех ранее описанных случаях, следует помнить, что запись ни в коем случае не должна вестись на сам восстанавливаемый раздел! Например, файл можно передать на соседний компьютер по сети. К сожалению, поле длины файла безжалостно затирается при его удалении, и реальный размер приходится определять "на глазок". В реальности эта задача намного проще, чем кажется на первый взгляд. Неиспользуемый хвост последнего фрагмента всегда забивается нулями, что дает хороший ориентир. Проблема заключается в том, что некоторые типы файлов содержат в своем конце некоторое количество нулей, при отсечении которых их работоспособность нарушается, поэтому тут приходится экспериментировать.

А что делать, если файл фрагментирован? Первые 13 блоков (именно блоков, а не фрагментов!) придется собирать руками. В идеальном случае это будет один непрерывный регион. Хуже, если первый фрагмент расположен в "чужом" блоке (т.е. блоке, частично занятом другим файлом), а оставшиеся 12 блоков находятся в одном или нескольких регионах. На практике, однако, достаточно трудно представить себе ситуацию, в которой первые 13 блоков были бы сильно фрагментированы, ведь UFS поддерживает фоновую дефрагментацию. Такое может произойти только при масштабной перегруппировке большого количества файлов, что в реальной жизни практически никогда не встречается. Поэтому будем считать, что 13-й блок файла найден. В массив непосредственной адресации он уже не помещается (там содержатся только 12 блоков), и ссылка на него, как и на все последующие блоки файла, должна содержаться в блоках косвенной адресации. Как вы помните, блоки косвенной адресации при удалении файла помечаются как свободные, но не затираются сразу же. Затирание происходит только по мере реальной необходимости, и это существенно упрощает нашу задачу.

Как найти этот блок на диске? Вычисляем смещение 13-го блока файла от начала группы цилиндров, переводим его во фрагменты, записываем получившееся число в обратном порядке (так, чтобы младшие байты располагались по меньшим адресам), и, наконец, осуществляем контекстный поиск по свободному пространству.

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

Внимание!

Если вы нашли несколько "кандидатов" на роль блоков косвенной адресации, это означает, что 13-й блок удаленного файла в разное время принадлежал различным файлам (а так, скорее всего, и будет). Не все косвенные блоки были затерты, поэтому принадлежавшие им ссылки остались неизменными.

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

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

Оптимизация производительности файловой системы

В отличие от Windows, Linux поддерживает целый спектр файловых систем различного типа и назначения: minix, ext2fs, ext3fs, ReiserFS, XFS, JFS, UFS, FFS… Какую файловую систему выбрать? Как правильно ее настроить? Стандартный выбор, предлагаемый составителями дистрибутива по умолчанию, не всегда оптимален. Как правило, быстродействие системы можно значительно улучшить.

Жесткий диск — надежное и быстрое устройство. Но процессор еще быстрее! И дисковая подсистема, несмотря на все усилия инженеров, по- прежнему остается слабейшим звеном, сдерживающим быстродействие всего компьютера в целом. А ведь объемы обрабатываемых данных все растут и растут.

Большинство материнских плат, выпущенных после 2000 года, несут на своем борту интегрированный RAID-контроллер, поддерживающий режимы RAID-0 ("stripe" mode — режим чередования, при котором данные пишутся на несколько жестких дисков сразу) и RAID-1 ("mirror" mode — зеркальный режим, при котором жесткие диски дублируют друг друга). Режим чередования значительно повышает производительность — два диска работают приблизительно в 1,5 раза быстрее, а четыре — примерно в 3,5 раза быстрее, чем один.

Обладатели ядра с версией 2.4 или более современной могут использовать программные реализации RAID (software RAID), практически не уступающие по скорости аппаратным реализациям. Стоит, правда, отметить, что программные RAID несколько повышают нагрузку на процессор. Более древние ядра (кстати говоря, уже практически вышедшие из употребления), скорее всего, потребуют установки дополнительного программного обеспечения. Более подробную информацию по данному вопросу можно найти здесь: http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html.

Большинство руководств настоятельно рекомендуют подключать программные RAID к различным IDE-каналам, т.е. разводить диски по "своим" шлейфам. Проблема в том, что типичная материнская плата имеет всего два IDE- канала. При этом, помимо жестких дисков требуется еще, как минимум, один оптический привод! Для достижения наивысшей скорости приходится приобретать материнскую плату, оснащенную несколькими каналами IDE. Что поделаешь — оптимизация требует жертв! В частности, плата EPOX 4PCA3+ содержит целых 6 каналов IDE, жаль лишь, что отнюдь не всем она по карману. На практике совмещать два жестких диска на одном шлейфе вполне возможно. Это совсем не страшно. Они могут работать почти параллельно (падение скорости составит около 15%). Современные накопители освобождают шину на время выполнения медленных операций, но шина все-таки одна, а накопителей два, вот им и приходится за нее конкурировать. А вот жесткий диск с оптическим приводом на одном шлейфе лучше не совмещать, так как в некоторых случаях скорость падает в разы. Чтобы выйти из этого положения, попробуйте отключить у оптического привода режим DMA, возможно, это поможет винчестеру заработать быстрее. Ряд примеров, иллюстрирующих производительность различных вариантов реализации программных RAID, приведены на рис. 8.13–8.15.

Рис. 8.13. Программный RAID (один диск — один канал)

Рис. 8.14. Программный RAID (два диска — два канала)

Рис. 8.15. Программный RAID (четыре диска — четыре канала)

Дисковый массив, состоящий из 12 винчестеров, подключенных к EPOX 4PCA3+, работает со сверхзвуковой скоростью, но и шумит точно так же, как и сверхзвуковой истребитель. При этом приходится покупать мощный блок питания на 350 Ватт и ставить специальные фильтры на разветвитель, чтобы подавлять помехи, к которым жесткие диски весьма чувствительны. Но выигрыш в скорости стоит того, особенно, если компьютер используется для занятий видеомонтажом или обработки изображений полиграфического качества. Но с такими потребностями лучше сразу обратится к дискам SCSI. Мы же остановимся на IDE как на самом демократичном и дешевом интерфейсе.

Настройка производительности с помощью утилиты hdparm

Для достижения наивысшей производительности каждый жесткий диск, установленный в систему, должен быть настроен в соответствии со своим предназначением. Стандартные настройки, принимаемые ядром по умолчанию, ориентированы на абстрактного среднестатистического пользователя и редко совпадают с конкретными требованиями. Учет преобладающего типа запросов к дисковой подсистеме значительно повышает быстродействие (в некоторых случаях — чуть ли не на порядок), хотя это оружие работает и в обратном направлении. Бестолковая настройка сваливает производительность в глубокую яму, из которой, впрочем, всегда можно выбраться, восстановив настройки по умолчанию.

Всем этим ведает консольная утилита hdparm (рис. 8.16), входящая в комплект штатной поставки большинства (если не всех) дистрибутивов Linux и требующая для своей работы полномочий администратора (root). Если вдруг этой утилиты в составе вашего дистрибутива не окажется, взять ее можно здесь: http://metalab.unc.edu/pub/Linux/system/hardware/hdparm-3.6.tar.gz. Формат ее вызова следующий: hdparm опция1 опция2... опцияN /dеv/ жесткий_диск

Рис. 8.16. Интерактивная оболочка утилиты hdparm

Жестким дискам с интерфейсом IDE обычно присваиваются имена hda (первый жесткий диск), hdb (второй жесткий диск), hdc и т.д. Диски SCSI, соответственно, именуются sda, sdb, sdc, вот только hdparm с ними, увы, не работает. Строго говоря, hdparm настраивает параметры не одного лишь жесткого диска, но и его контроллера и, отчасти, драйвера. Рассмотрим несколько практических примеров.

Ключ -а устанавливает количество секторов опережающего чтения (read-ahead), которые будут автоматически прочитаны контроллером в надежде на то, что они все-таки пригодятся пользователю. По умолчанию ядро читает 8 секторов (4 Кбайт). При последовательном чтении больших слабо фрагментированных файлов это значение рекомендуется увеличить в несколько раз, а при хаотичном доступе, работе с мелкими или сильно фрагментированными файлами — уменьшить до 1–2 секторов. Ключ -P задействует механизм аппаратной предвыборки (hardware prefetching), сообщая приводу, сколько секторов ему необходимо прочитать. Грубо говоря, эта опция производит почти тот же самый эффект, что и -а, только намного круче. Тем не менее, следует иметь в виду, что не все приводы поддерживают аппаратную предвыборку.

Ключ -m указывает количество секторов, обрабатываемых приводом за одну операцию обмена (так называемый multiple sector I/O или block mode). В зависимости от конструктивных особенностей жесткого диска он может обрабатывать от 2 до 64 (и больше) секторов за операцию. Конкретное значение можно узнать с помощью ключа -i (оно находится в графе MaxMultSect). В целом, скорость обработки данных прямо пропорциональна количеству секторов, однако некоторые приводы (например, WD Caviar) при больших значениях -m начинают жутко тормозить. Выяснить практическое положение дел помогает ключ -t, измеряющий пропускную способность дисковой подсистемы в режиме чтения.

Внимание!

Запредельные значения -m могут привести к повреждению данных. По этой причине рисковать, экспериментируя с этим параметром, без необходимости не рекомендуется!

Ключ -M отвечает за настройку шумовых характеристик накопителя (Automatic Acoustic Management, AAM). Значение 128 соответствует наиболее тихому режиму, 254 — наиболее быстрому. Промежуточные значения в общем случае не определены (некоторые накопители их поддерживают, некоторые нет). Следует сказать, что значение 128 не только уменьшает шум, но и способствует меньшому износу накопителя, однако падение производительности может быть очень и очень значительным, поэтому трудно посоветовать, какое именно значение следует выбрать.

Ключ -c управляет режимом передачи данных. Параметр 0 — 16-битная передача, 1 — 32-битная передача, 3 — 32-битная передача со специальным синхросигналом. По умолчанию ядро использует параметр 3 (возможно, не для всех ядер), как наиболее надежный, но и менее производительный, чем 1. Большинство современных чипсетов вполне нормально работают с параметром 1, так что излишняя осторожность тут ни к чему.

Ключ -d1 активирует, a _-d0 дезактивирует режим DMA, значительно повышающий производительность и радикально снижающий нагрузку на процессор. Однако на практике так бывает далеко не всегда. Устройства IDE, висящие на одной шине, могут конфликтовать между собой, и тогда хотя бы одно из них должно быть принудительно переведено в режим PIO. Выяснить, как обстоят дела в каждом конкретном случае, помогает ключ -T, измеряющий скорость передачи данных. Ключ -d1 обычно используется совместно с ключом -Xnnn, форсирующим конкретный режим PIO или DMA. Режиму PIO n соответствует значение (n + 8), т.е. -X9 задает PIO1, a -X12 — PIO4. Режиму DMAn соответствует значение (n+32), например, -X34 для DMA2, a Ultra DMA — (n+64), например, -Х69 для UDMA5, который обеспечивает наивысшую производительность, но поддерживается не всеми жесткими дисками и чипсетами. Узнать список поддерживаемых режимов можно с помощью ключа -i. По умолчанию ядро выбирает не слишком агрессивные режимы передачи данных, оставляя солидный запас производительности за спиной.

Внимание!

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

Для сохранения установок необходимо дать команду hdparm -k 1 /dev/hdx, в противном случае они будут утеряны при первом же сбросе контроллера IDE или перезапуске машины.

Выбор файловой системы

Существует два типа файловых систем — журналируемые (journaling) и нет. К первым относятся ext3fs, ReiserFS, XFS, а последним — minix, ext2fs и UFS. Журналирумые файловые системы намного легче переносят зависание системы и отключение питания во время интенсивных дисковых операций, автоматически возвращая файловую систему в стабильное состояние. Однако от других типов разрушений (отказ контроллера, дефекты поверхности, вирусное нашествие) журналирование уже никак не спасает, а вот производительность падает изрядно.

Для домашних компьютеров и большинства рабочих станций журналирование не нужно, и надежности файловой системы ext2fs вполне достаточно, особенно если компьютер оборудован источником бесперебойного питания. В ответственных случаях используйте ext3fs или ReiserFS. По тестам ReiserFS в среднем вдвое, а на операциях записи — в 35 раз быстрее, чем ext3fs, что особенно хорошо заметно на мелких файлах. В реальности же часто все бывает наоборот. Высокая латентность ReiserFS (промежуток между подачей запроса и получением ответа) вкупе с агрессивной загрузкой процессора приводят к заметному отставанию от ext3fs, что особенно хорошо заметно на мелких файлах (да-да, на тех самых, на которых нам обещали выигрыш!). Подробнее об этом можно прочитать здесь: http://kerneltrap.org/node/view/3466.

Журналирование можно значительно ускорить, если разместить журнал на отдельном носителе. Такой журнал называется внешним (external). Подключить его можно командной строкой следующего вида: tune2fs -J device= external_journal (где external_journal — имя раздела соответствующего устройства), причем внешний журнал должен быть предварительно создан командой mke2fs -О journal_dev external_journal. Команда tune2fs -J size= journal_size управляет размером журнала. Чем меньше размер журнала, тем ниже производительность. Предельно допустимый размер составляет 102 400 блоков или ~25 Мбайт (точное значение зависит от размера блока, о котором мы еще поговорим).

По умолчанию ext3fs журналирует только метаданные (т.е. служебные данные файла, например, такие как inode), записывая их на диск только после того, как будет обновлен журнал. Для увеличения быстродействия можно задействовать "разупорядоченный" режим, в котором метаданные записываются одновременно с обновлением журнала, что соответствует команде: mount /dev/hdx /data -о data=writeback. Естественно, надежность файловой системы при этом снижается. При желании можно журналировать все данные (команда mount /dev/hdx /data -о data= journal), после чего никакие зависания или отказы питания нам будут не страшны, правда о производительности придется забыть.

При создании новой файловой системы важно выбрать правильный размер блока (в терминологии MS-DOS/Windows — кластера). На ext2fs и ext3fs это осуществляется командой mke2fs -b block-size, на XFS — mkfs.xfs -b size=block-size и newfs -b block-size — на UFS. Чем больше блок, тем ниже фрагментация, но и выше дисковые потери за счет грануляции дискового пространства. Некоторые файловые системы (например, UFS) поддерживают фрагменты (fragments) — порции данных внутри блоков, позволяющие задействовать свободное пространство в "хвостах" блоков, благодаря чему использование блоков большого размера уже не приводит ни к каким потерям. Файловая система ReiserFS, в отличие от остальных, не нарезает диск на ломтики фиксированного размера, а динамически выделяет требуемый блок данных, забивая диск файлами под завязку. В среднем это на 6% увеличивает доступный объем, однако приводит к чрезмерной фрагментации, "съедающей" всю производительность. Рекомендуется использовать максимально доступный размер блока (4 Кбайт для ext2fs и ext3fs, 16 Кбайт для UFS и 64 Кбайт для XFS, файловые системы ReiserFS и JFS не поддерживают этой опции) и задействовать максимальное количество фрагментов на блок (в UFS — 8).

Другая важная опция определяет режим хеширования каталогов. Для ускорения работы с каталогами, содержащими большое количество файлов и подкаталогов, каталог должен быть организован в виде двоичного дерева. В ext2fs и ext3fs это осуществляется командой mke2fs -о dir_index, а в ReiserFS — mkreiserfs -h HASH, где HASH — один из следующих типов хэш-таблицы: r5, rupasov или tea. По умолчанию выбирается тип r5, который наилучшим образом подходит для большинства файловых операций. Тем не менее, некоторые приложения (например, Squid Web Proxy-сервер) настоятельно рекомендуют использовать rupasov-хэш, в противном случае за быстродействие никто не ручается. С другой стороны, r5 и rupasov очень медленно работают с каталогами, содержащими по несколько миллионов файлов, и здесь лучше подходит tea, а на каталогах из нескольких десятков файлов все три алгоритма хеширования проигрывают стандартному нехешируемому plain-алгоритму. К сожалению, опция хеширования носит глобальный характер — нельзя одни каталоги хешировать, а другие — нет.

Файловая система XFS — единственная из всех, которая позволяет задавать размер inode вручную. Обычно в inode хранятся служебные данные файла (атрибуты, порядок размещения блоков на диске), но если файл целиком помещается в inode, то система сохраняет его именно там! Дополнительное дисковое пространство уже не выделяется, что избавляет головку винчестера от лишних перемещений, в результате чего время доступа к файлу существенно сокращается. Точно так же поступают ReiserFS, NTFS и некоторые другие файловые системы, однако размер inode они менять не в состоянии, а жаль! Если мы планируем работать с большим количеством мелких файлов, размер inode желательно увеличить, что положительно скажется как на производительности, так и на доступном дисковом пространстве. При работе с большими файлами размер inode лучше, наоборот, сократить, в противном случае потери дискового пространства будут довольно значительными. Выбор предпочтительного размера inode осуществляется командой следующего вида: mkfs.xfs -i size=value. Минимальный размер составляет 512 байт, максимальный — 2048.

Внимание!

Windows предоставляет минимум рычагов управления для настройки дисковой подсистемы, и угробить свои данные под ее управлением довольно затруднительно. Linux же позволяет "крутить" и настраивать вся и все! Как следствие — малейшая оплошность приводит к катастрофическим разрушениям. И винить в этом некого — нечего было браться за штурвал, не выучив руководство, как правило, написанное на английском языке. Но даже хорошо написанное руководство не поможет определить, какие именно режимы поддерживаются вашим оборудованием, а какие — нет. Вполне может оказаться и так, что у вас кабель перекручен или разъем барахлит, а на высокосортных режимах это сразу же скажется! Настройка дисковой подсистемы на максимальную производительность — это огромный риск! Никогда не экспериментируйте, не зарезервировав всех данных!

Фрагментация

В процессе работы с диском его фрагментация неизбежно увеличивается. Больше всего от этого страдают ext2fs/ext3fs и ReiserFS. На UFS и XFS за счет поддержи блоков большого размера падение производительности уже не так заметно. Утверждение, что файловые системы Linux якобы не подвержены фрагментации — нелепый миф, который легко опровергнет любой опытный пользователь.

При последовательной записи на диск нескольких файлов система их размещает один за другим, так что первый файл "упирается" во второй. Свободного места для дальнейшего роста уже нет (короткий "хвост" в конце блока не считается), и система вынуждена выделять блоки где-то за концом следующего файла. Если же их там нет, свободные блоки ищутся в начале диска. В результате этого файл оказывается "размазанным" по поверхности диска. Рассмотрим еще один сценарий. Представьте себе, что вы записали пять файлов по 100 блоков каждый, а затем удалили первый, третий и пятый файлы. Таким образом, вы освободите 300 блоков в трех фрагментах. При записи 300-блочного файла система сначала попытается отыскать непрерывный участок свободного пространства подходящего размера, но если его не окажется, будет вынуждена "размазывать" файл по поверхности. Чтобы исправить ситуацию, необходимо собрать все свободные блоки, объединив их в один непрерывный фрагмент, т.е. дефрагментировать раздел.

С моей личной точки зрения, из бесплатных дефрагментаторов лучшим является стандартный defrag, входящий в штатный комплект поставки большинства дистрибутивов Linux. Если же в вашем дистрибутиве его нет, исходные тексты дефргаментатора можно скачать по следующему адресу: ftp://metalab.une.edu/pub/Linux/system/filesystems/defrag-0.70.tar.gz.

Фирма OO-Software, наряду с одноименным дефрагментатором для Windows NT, выпустила замечательный консольный дефрагмантатор для Linux, в настоящее время находящийся в стадии бета-тестирования и распространяющийся на бесплатной основе. Так что качайте его, пока дают, а скачать его можно отсюда: http://www.oo-software.com/cgi-bin/download-e.pl?product=OODLXBIN.

Регулярная дефрагментация — это хороший способ противостоять растущему падению производительности файловой системы.

Обновлять или не обновлять

Некоторые приложения, в частности, уже упомянутый Squid Web Proxy-сервер, требуют особой настройки файловой системы. Для увеличения быстродействия рекомендуется отключить обновления времени последнего доступа к файлу с помощью команды mount -о noatime. Наибольший прирост производительности наблюдается на UFS, которая, в отличие от подавляющего большинства остальных файловых систем, не откладывает обновление inode в долгий ящик (lazy write), а делает это сразу же после его изменения (write through). На ext3fs в силу ее журналирующей природы, обновление atime вносит столь незначительный вклад в общее быстродействие, что никакой разницы просто нет.

Проблема "хвостов"

По умолчанию ReiserFS сохраняет короткие файлы (и файловые хвосты) на листьях двоичных деревьев. В целом, это многократно повышает производительность, особенно если свободное дисковое пространство далеко от исчерпания (рис. 8.17 и 8.18). Тем не менее, при работе с некоторыми приложениями "хвосты" лучше отключить. При работе с огромным количеством мелких файлов, которые постепенно растут, системе приходится перестраивать большое количество структур данных, "гоняя" растущие хвосты между блоками и деревьями, в результате чего производительность становится недопустимо низкой. Команда mount -о notail отключает "паковку" хвостов и коротких файлов. Повторное монтирование с настройками по умолчанию вновь активизирует эту опцию, но при этому уже "упакованные"/"распакованные" хвосты останутся на своем месте вплоть до модификации "своего" файла.

Рис. 8.17. Производительность файловой системы ReiserFS на операциях записи в зависимости от объема свободного пространства (паковка хвостов включена)

Рис. 8.18. Производительность файловой системы ReiserFS на операциях записи в зависимости от объема свободного пространства (паковка хвостов выключена)

Внимание!

Помните, что mke2fs — это деструктивная команда, разрушающая всю файловую систему целиком! Грубо говоря, это format.com под Linux.

Полезные ссылки

□ "The Software-RAID HOWTO" — руководство по созданию программных RAID'ов под Linux (на английском языке): http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html.

□ "Тонкая настройка IDE дисков в Linux с помощью hdparm" — отличная статья на русском языке. Доступна здесь: http://www.opennet.ru/base/sys/htparm_tune.txt.html.

□ "JFS for Linux" — домашняя страничка проекта JFS. Содержит исходные тексты, документацию, технологию и т.д. (на английском языке): http://jfs.sourceforge.net/.

□ "ReiserFS" — домашняя страничка проекта ReiserFS (на английском языке): http://www.namesys.com.

□ "Работа с дисками и файловыми системами в FreeBSD" — отличный faq на русском языке: http://www3.opennet.ru/base/sys/freebsd_fs_mount.txt.html.

□ "Understanding Filesystem Performance for Data Mining Applications" — сравнение производительности различных файловых систем под Linux с советами по их "тонкой" настройке (на английском языке): http://www.cs.rpi.edu/~szymansk/papers/hpdm03.pdf.

□ "Linux Filesystem Performance Comparison for OLTP" — еще одна статья по сравнению производительности файловых систем под Linux (на английском языке): http://otn.oracle.com/tech/linux/pdf/Linux-FS-Performance-Comparison.pdf.

□ "Journaling file systems" — журналируемые файловые системы и все, что с ними связано (на английском языке): http://awlinux1.alphaworks.ibm.com/developerworks/linux390/perf/tuning_res_journaling.shtml.

□ "Linux: Low Latency and Filesystems" — обсуждение преимуществ и недостатков ReiserFS (на английском языке): http://kerneltrap.org/node/view/3466.

□ "Ext3 or Reiserfs? Hans reiser says red hat's move is understandable" — еще одно сравнение ext3fs и ReiserFS (на английском языке) http://www.linuxplanet.com/linuxplanet/reports/3726/1/.

□ "Optimizing Linux filesystems" — отличная статья про оптимизацию файловых систем под Linux (на английском языке): http://www.newsforge.com/article.pl?sid=03/10/07/1943256.

□ "Journaling-Filesystem Fragmentation Project" — исследовательская работа по фрагментации файловых систем и ее влиянию на производительность (на английском языке): http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/agesystem.html.

□ "HDD REPAIR FORUMS" — форум по тестированию жестких дисков и восстановлению данных (на русском языке): http://mhddsoftware.com/forum/.

□ "Filesystem defragmenter for Linux filesystems" — исходные тексты стандартного дефрагментатора: ftp://metalab.unc.edu/pub/Linux/system/filesystems/defrag-0.70.tar.gz.

□ "О&О Defrag Linux BETA - 1.0.4761" — бета-версия хорошего коммерческого дефрагментатора: http://www.oo-software.com/cgi-bin/download/download-e.pl?product=OODLXBIN.

Часть III Восстановление поврежденных носителей резервных копий

Глава 9 Восстановление данных с носителей остальных типов

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

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

Кого трогает чужое горе? К этим людям уж точно нельзя причислить специалистов из сервисных центров. Они просто делают свою работу, т.е. зарабатывают деньги с наименьшими телодвижениями. А по-другому и не получится. Рынок! Если принимать близко к сердцу чужие проблемы, то через месяц работы можно слечь с инфарктом. Бесспорно, у специалистов есть опыт, оборудование и все прочие составляющие, необходимые для успешного восстановления данных. Неквалифицированные попытки "самолечения" в девяти случаях из десяти заканчиваются полным провалом и необратимым уничтожением тех данных, которые еще можно было бы спасти. Тем не менее, обращение к специалистам далеко не всегда оправдано. Это особенно справедливо, если речь идет о конфиденциальной информации.

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

Оптические носители

Начнем с восстановления носителей CD/DVD, как с наиболее распространенных на сегодняшний день носителей информации. Производители наперебой уверяют потребителей в исключительной надежности своей продукции. Но при этом диски мрут, как мухи, зачастую выдерживая всего лишь один сезон. Сотрудники тестовой лаборатории датского отделения журнала PC-Active провели свое собственное расследование. Отобрав несколько "брендовых" разновидностей, они исследовали процессы деградации в активном слое и получили шокирующие результаты. На рис. 9.1 изображены фотографии лазерного диска, полученные с помощью специального оборудования. Слева представлен диск сразу после прожига, справа — тот же самый диск спустя 20 месяцев. Белый цвет обозначает идеальные сектора, светло-серый — сектора, в процессе чтения которых изредка возникают ошибки чтения, и, наконец, более темные оттенки соответствуют секторам, имеющим серьезные повреждения. Несмотря на то, что внешне такой диск читается вполне нормально, поскольку корректирующие коды Рида-Соломона делают свое дело, с каждым днем он будет читаться все хуже.

Рис. 9.1. Деградация активного слоя носителей CD-R с течением времени

Чтобы избежать неприятных сюрпризов, свой архив на оптических носителях следует тестировать, по крайней мере, раз в шесть месяцев. Для этого подойдет любая программа (лично я предпочитаю NERO quality test). Если такой программы под рукой нет, то качество носителя можно приблизительно оценить по звуку, издаваемому приводом. Если диск читается на полной скорости без характерных повторов и сброса оборотов — с ним все OK. В противном случае данные необходимо как можно скорее переписать на свежий носитель.

А что делать, если вы спохватились уже после того, как диск перестал читаться? Самое простое — затормозить привод до скорости 4x–8x (если, конечно, он это позволяет) и повторить попытку еще раз. Существует множество "тормозящих" утилит, например, разработанная мною программа xCD, которую можно найти на компакт-диске, прилагаемом к этой книге. К сожалению, не все приводы поддерживают программное изменение скорости, и далеко не все они читают "проблемные" диски, так что тут придется поэкспериментировать. Попробуйте прочитать диск у приятелей или зайдите в ближайшую фирму и попросите продавца "протестировать" привод перед его "покупкой". Впрочем, шансы на успешный исход дела не так уж и велики. И что тогда?

Практика показывает, что существует всего две основных причины, по которым диски перестают читаться: царапины и дегенеративные процессы в активном слое. Ну, с царапинами мы еще разберемся, а что делать с активным слоем, контрастность которого необратимо снижается со временем? Проблему можно решить, повысив мощность лазерного излучателя. Прием варварский, но других путей, по-видимому, просто нет. Лазеру, конечно, проходится туго, и долго в таком режиме он не проработает. Однако прежде чем окончательно отказать, он может успеть кое-что прочитать. Приводы прошлого поколения содержали подстроечные резисторы, регулируемые любой отверткой, но сейчас их заменила электроника. Яркость лазерного луча настраивается автоматически, и чтобы се изменить, необходимо пропатчить прошивку (а это не каждому по плечу). Как вариант, можно найти на плате постоянный резистор, ведущий к излучателю, и припаять параллельно ему еще один, уменьшая эффективное сопротивление в 1,5–2 раза. Естественно, к этой мере следует прибегать только в тех случаях, когда на диске оказались действительно важные данные, стоимость которых сопоставима с ценой привода.

Теперь о царапинах. Даже глубокие борозды — это еще не приговор. Некоторые источники рекомендуют отполировать диск зубным порошком (который сейчас трудно найти в продаже) или специальной шлифовальной пастой типа ГОИ. Все это правильно, и такая методика отлично работает, но тут есть два маленьких "но". Во-первых, с первой попытки отполировать диск не удастся. Тут навык необходим! А чтобы его получить, требуется затратить уйму времени, которое не у всех есть. Во-вторых, глубокие царапины просто так не зашлифуешь, а ведь именно они — источник всех бед! Нет, мы пойдем другим путем. Возьмем зеленку (ту самую, что продают в аптеках) и аккуратно закрасим царапины зубочисткой или остро заточенной спичкой. Это предотвратит рассеивание света, а для лазерного луча зеленка прозрачна!

Хуже, если диск раскололся на несколько частей. Можно ли спасти хотя бы часть данных? Некоторые фирмы, специализирующиеся на восстановлении, используют электронные микроскопы, фотографирующие спиральную дорожку. Далее они проводят компьютерную обработку собранной информации, буквально по байтам восстанавливая утраченные файлы. Это — довольно кропотливое и весьма дорогостоящее занятие, которое по карману только крупным компаниям, потерявшим судьбоносные данные. В домашних условиях обычно используется двусторонний строительный скотч и пустая болванка, к которой приклеиваются обломки диска, после чего эта конструкция аккуратно вставляется в привод, работающий на скорости 1х–2х. Конечно, для чтения используется специальное программное обеспечение (которое, в частности, можно найти на прилагаемом к книге CD) и прочие ухищрения, но, тем не менее, какая-то часть информации все же читается. Попробуем рассчитать, какая же именно. Размер одного сектора составляет ~15 мм, для позиционирования головки привод должен декодировать субканальную информацию, для чего ему необходимо прочитать не менее 11 секторов. Следовательно, данная технология позволяет читать обломки с длинной дуги от ~17 см. Для внешней кромки это составляет чуть меньше половины лазерного диска, т. е. если диск разломать напополам, мы сможем прочесть лишь ту часть информации, что была записана на самом краю. Не слишком-то воодушевляющая перспектива, но это все-таки лучше, чем совсем ничего.

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

ZIP-дискеты

Будучи достаточно надежными носителями, ZIP-дискеты особых проблем не вызывают, и сбойные сектора на них встречаются крайне редко. Тем не менее, они все-таки встречаются. Корнем зла могут быть и магнитные поля от монитора или системного блока, и дефекты поверхности (в основном встречающиеся на "не фирменных" дискетах типа FUJIFILM), да и много чего еще! Как правило, нечитающийся диск еще можно спасти, если многократно повторять операцию чтения в цикле. Любой дисковый "доктор" с этим справится! В отличие от классических дискет, где головка трется о поверхность, в приводах ZIP она летает над поверхностью диска, и потому многократное чтение никак не сказывается на "здоровье" носителя. Короче говоря, хуже не будет. Исключение составляют приводы с поврежденной головкой, царапающей диски, но это уже клинический случай, который мы не рассматриваем. Видели табличку в лифте: "запрещается пользоваться неисправным лифтом"? Вот точно так же обстоят дела и с приводами ZIP.

Кстати говоря, после каждой серии неудачных попыток чтения желательно выполнять позиционирование головок на удаленные сектора, а потом возвращать их обратно. Смысл этой операции в том, чтобы заставить головки подходить к проблемному сектору под различными углами, надеясь, что в каком-то положении он все-таки почитается. Стандартные дисковые доктора вроде scandisk/chkdsk, входящие в комплект штатной поставки Windows, этого делать не умеют. Norton Disk Doctor, известный в народе как Norton Disk Destroyer, тоже не отличается интеллектом. Поэтому единственной утилитой, ориентированной на восстановление ZlP-носителей, была и остается SpinRite Стива Гибсона, которую можно найти в e-Mule. Она восстанавливает 90% нечитающихся дисков, а по некоторым оценкам —даже больше того!

С дискетами-убийцами все обстоит значительно сложнее, и просто так вставлять их в дисковод нельзя! То же самое относится и к дискетам с подвернутым краем (рис. 9.2). Если это сделать, то вы сразу же услышите "щелчок смерти" (Click of Death), и заведомо исправный привод немедленно выйдет из строя. Как появляются такие дискеты, ведь головки чтения/записи теоретически вообще не должны касаться поверхности? Вот, например, нерадивый пользователь, отодвинув защитную шторку, лезет туда пальцем, или дискета упирается в поврежденную магнитную головку. Если столкновение с головками испытал край диска, то на его кромке образуется одна или несколько относительно больших зазубрин. Как следствие, такая дискета начинает уничтожать все ZIP-приводы, которые только встретятся ей на пути. К счастью, нулевая дорожка располагается вблизи центра, и потому файловая система поврежденной дискеты не страдает, и ее все еще можно прочитать.

Рис. 9.2. Дискета-убийца с подвернутым краем

Нам потребуется тонкий скальпель или бритва. Необходимо вскрыть дискету, не повредив ни корпуса, ни магнитного покрытия. Это легко. Любой домашний мастер с этим справится! Теперь, вооружившись размагниченными ножницами, обрежем подвернутый или разорванный край так, чтобы не осталось заусениц (размагничивание обычно осуществляется вращательными движениями дросселя, включенного в сеть, если у вас нет дросселя — обратитесь к любому радиомастеру — он поможет). Собираем дискету, но ни в коем случае не вставляем ее в дисковод! Конструкция привода ZIP выполнена так, что головки, сойдя с парковочной зоны, ожидают "увидеть" под собой магнитную поверхность дискеты. Если ее там не окажется, то привод погибнет вместе с дискетой. Чтобы этого не произошло, между "коромыслами" необходимо ввести какой-нибудь предмет, например, авторучку, и затем удалить его, когда головки достигнут поверхности диска. Кроме того, читать последние сектора дискеты недопустимо, иначе головки войдут в "отрезанную" зону и умрут, нанося дискете дополнительные повреждения.

Внимание!

Ничего не скрывая и не лукавя, я скажу, что риск угробить привод во время всех этих манипуляций очень велик. Как минимум, его необходимо разобрать, что автоматически приведет к потере гарантии. Так что, взявшись за это дело, можете сразу же отправить гарантийный талон в мусорное ведро. Но по-другому, увы, никак не получается! Что поделаешь! Борьба с энтропией требует серьезных денежных вложений и не менее серьезных усилий! Более подробную информацию о проблеме Click of Death, включая FAQ, инструкцию по разборке, сборке и тестированию приводов ZIP на исправность, а также бесплатную утилиту Trouble in Paradise, выполняющую такое тестирование, и многое другое можно найти здесь: http://www.grc.com/tip/clickdeath.htm. В русском переводе ту же самую информацию можно найти здесь: http://www.ixbt.com/storage/clickofdeath.html.

Магнитные ленты

Картриджи для стримеров очень долговечны и крайне надежны. Обычно с ними не случается никаких проблем, но иногда лента все-таки рвется. Виновником может быть как "мcтитeльный" стример, плохо сконструированный и собранный в подпольной фирме кустарным образом "из чего бог послал", так и сам человек. Очень многие из нас питают нездоровое влечение к магнитным лентам. Кто не пробовал их потеребить, поковырять ножиком или даже карандашом?

Хорошая новость! Порванную ленту можно склеить любым универсальным клеем. Лично я предпочитаю польский "Суперцемент", который очень трудно найти в магазинах. Однако японский Super Glue, который сейчас продается в крошечных тюбиках на каждом углу, подходит ничуть не хуже. Вопреки распространенному мнению, потери информации при этом не происходит! Стримеры используют помехозащитные коды (разновидность циклических кодов Рида-Соломона) и безболезненно переносят значительные "выпадения" ленты, вплоть до 5 см (конкретные цифры варьируются от модели к модели).

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

Дефектные стримеры при определенных обстоятельствах иногда мнут ленту, что уже значительно хуже. Измятая лента не прилегает к магнитной головке и читается с огромным количеством ошибок, с которыми корректирующие коды уже не справляются. Что тогда? К счастью, в отличие от кассетного магнитофона, в котором запись происходит перпендикулярно движению ленты, в стримере запись производится под некоторым углом, отличным от 90 градусов. В результате этого влияние локальных дефектов значительно ослабляется. Чтобы прочитать измятую ленту, в девяти из десяти случаев достаточно увеличить ее прижим к головке (для этого подойдет небольшой кусочек поролона или другого упругого материала со скользким покрытием). Многократное вычитывание поврежденных участков дает неплохой результат, и значительная часть информации все же возвращается из небытия.

Некоторые люди пытаются разгладить ленту руками, ногтем или другим "инструментом". Этого делать нельзя!!! Лента вытягивается, и потому время ее чтения увеличивается, а стример рассчитан на строго определенную скорость, и изменение частоты сигнала создает дополнительную нагрузку на корректирующие коды, которым и без того приходится тяжело. Впрочем, это уже крайности, с которыми большинство пользователей стримеров никогда не встречается.

FLASH-память

Термин "FLASH-память" охватывает целый спектр устройств, на краю которого находятся мини-драйвы, по сути представляющие собой миниатюрные жесткие диски. Естественно, к каждому типу устройств нужен индивидуальный подход, и принципы их восстановления различны.

Давайте рассмотрим тип FLASH-носителей, которые состоят из перепрограммируемой микросхемы энергонезависимой памяти и контроллера USB, так как он встречается чаще всего. Микросхема памяти довольно надежна и отказывает, прямо скажем, не очень часто. Что же касается контроллера USB, то он легко выводится из строя вездесущим статическим электричеством, да и вообще довольно-таки уязвим. Если только память и контроллер USB не интегрированы в единую микросхему, то контроллер легко перепаять. Достаточно купить еще один FLASH-носитель точно такой же или аналогичной модели. Естественно, для этого необходимо уметь держать паяльник в руках, иначе данные умрут окончательно. Современные микросхемы очень боятся перегрева, и стоит нам лишь чуть-чуть замешкаться, как они тут же гибнут бесповоротно.

Впрочем, аппаратные отказы FLASH-карт — это все-таки экзотика. Гораздо чаще приходится сталкиваться с логическими разрушениями, например, вроде ошибочно удаленных файлов или неполадок работы драйвера. Глюки — это настоящая проблема. Из-за них погиб Mars Rover (http://www.esolpartners.com/shared/pdf/Spirit_Rover_8.23.04.pdf), да и вообще теряется огромное количество данных. Суть в том, что часть памяти зарезервирована под служебные нужды, но доступ к ней не заблокирован, поэтому программными средствами можно не только прочесть эту область, но и записать в нее все, что угодно. Если драйвер по ошибке или злому умыслу затирает служебную область, доступ к FLASH-карте чаще всего становится невозможным. Мы не можем даже отформатировать ее, не говоря уже о том, чтобы считать данные. Несколько лет назад, когда карты были дорогими, это становилось настоящим потрясением. Впрочем, всегда было можно найти устройство, которое игнорирует служебную область и работает с картой без нее, а это значит, что низкоуровневый доступ к FLASH-памяти все же работал! А раз так — можно считать все данные и самостоятельно декодировать их.

Восстановлением FLASH-карт занимается множество утилит. Лично я предпочитаю Photo Rescue (http://www.photorescue.net/) от создателя легендарного дизассемблера IDA PRO. И хотя она позиционируется как средство "спасения" цифровых фотографий, восстановление "обычных" данных проходит ничуть не хуже. Это — платный продукт, за который придется выложить $30 или даже $40 (Expert Edition), однако Evaluation-версия раздается бесплатно всем желающим.

Чтобы никогда не заниматься восстановлением резервных копий (а это — занятие не из приятных), всегда дублируйте все критические данные. Тогда при отказе одного из носителей вам не придется хвататься за сердце и глушить корвалол. Поверьте, время, затраченное на резервирование, не идет ни в какое сравнение с расходами на восстановление!

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

Записываемые и перезаписываемые лазерные диски представляют собой идеальное средство для резервирования информации умеренных объемов (а всякий администратор обязательно должен заботиться о периодическом резервировании вверенной ему информации!). К сожалению, никакая работа без ошибок не обходится. Что поделаешь — человеку свойственно ошибаться — Errare humanum est, как говорили древние. Ошибочное удаление файлов с носителей CD-R/CD-RW, равно как и непредумышленная очистка последних, хотя бы однажды, да случается. Кстати, как показывает практика, с этим явлением приходится сталкиваться далеко не однажды, особенно если пользователи самостоятельно резервируют ту или иную информацию на CD-R/CD-RW.

Насколько мне известно, утилит, предназначенных для восстановления информации с лазерных дисков, до сих пор не разработано. Во всяком случае, такие утилиты не были широко представлены на рынке. Поэтому в подавляющем большинстве случаев восстановлением испорченных дисков приходится заниматься самостоятельно.

Восстановление удаленных файлов с CD-R/CD-RW

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

Рассмотрим, например, как осуществляется удаление файлов с CD-R/RW. Нет, это не опечатка! Содержимое дисков CD-R, несмотря на физическую невозможность их перезаписи, в принципе все же уничтожаемо. Для имитации удаления файла программы записи на CD просто не включают ссылку на уничтожаемый файл в файловую систему последней сессии. Следует, правда, заметить, что эта возможность дарована далеко не всем программам. Например, Roxio Easy CD Creator может поступать таким образом, a Stomp Record Now! — нет. И хотя "удаленный" файл все еще присутствует на диске, "отъедая" часть дискового пространства, при просмотре содержимого диска штатными средствами Windows он уже не отображается в каталоге. Если удалению одних файлов сопутствует запись других, то в любом случае приходится открывать новую сессию, а каждая вновь открываемая сессия требует для своего размещения определенного пространства. Какой же тогда смысл в удалении файлов с CD-R, если объем свободного пространства на диске при этом не увеличивается, а даже уменьшается? На самом же деле смысл этой операции (если, его вообще можно назвать "смыслом") заключен исключительно в сокрытии "удаляемых" файлов от простых пользователей. Раз удаленные файлы не видны при просмотре содержимого диска штатными средствами, то неквалифицированному пользователю они формально недоступны.

Примечание

Здесь уместно подчеркнуть, что "недоступны" эти файлы будут только для штатных средств операционной системы Windows. Например, компьютеры Macintosh позволяют монтировать любую сессию диска на отдельный том, благодаря чему при просмотре многосессионных дисков на Macintosh все якобы удаленные файлы сразу же "всплывают".

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

Внимание!

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

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

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

Рис. 10.1. Анализ содержимого диска на предмет выявления удаленных файлов

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

Поиск по сайту: