4.9. Демонтирование файловых систем

Демонтирование файловой системы делает ее недоступной для чтения и записи, файлы, которые расположены на демонтируемом разделе, конечно же, остаются на месте. Просто после демонтирования они не видны: точка монтирования снова превращается в пустой каталог, как это было до монтирования в нее диска или раздела.

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

Демонтирование файловой системы выполняется командой umount. Синтаксис команды следующий:

umount mount_point

Например:

$ umount /mnt

4.10. Проверка и восстановление файловых систем

Файловая система ОС UNIX надежна и выполняет значительную работу, справляясь с неожиданными крахами системы и отказами аппаратных средств. Но рано или поздно любая файловая структура оказывается поврежденной. Администратор системы несет ответственность за восстановление таких структур.

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

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

Незначительные повреждения обычно поддаются устранению с помощью команды fsck (file system consistency check – проверка целостности файловой системы).

Ниже перечислены пять наиболее часто встречающихся видов повреждений:

• наличие индексных дескрипторов, на которые нет указаний;

• неоправданно большие счетчики ссылок;

• неиспользуемые блоки данных, не отраженные в картах блоков;

• блоки данных, указанные как свободные, но используемые в файле;

• неверная общая информация в суперблоке.

Команда fsck устраняет все эти проблемы автоматически. Диски обычно проверяются во время начальной загрузки с помощью команды fsck –p, которая исследует локальные файловые системы, описанные в файле /etc/fstab (или /etc/checklist), и исправляет указанные выше пять ошибок.

Команду fsck –p можно выполнить и для отдельной файловой системы.

Например:

$ fsck –p /dev/dsk/c0d0s7

** /dev/rdsk/c0d0s7

** Currently Mounted on /export/home

** Phase 1 - Check Blocks and Sizes

** Phase 2 - Check Pathnames

** Phase 3 - Check Connectivity

** Phase 4 - Check Reference Counts

** Phase 5 - Check Cyl groups

2 files, 9 used, 3823540 free (20 frags, 477940 blocks,0.0% fragmentation)

Ошибки, не относящиеся ни к одной из пяти вышеуказанных категорий, потенциально опасны. Они заставляют fsck –p вывести призыв о помощи и завершить свою работу. В этом случае нужно запустить fsck без опций, и при прогоне в ручном режиме давать подтверждение на каждую восстановительную операцию, которую программа собирается выполнить.

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

Помните: каждый раз пытаясь обратиться к поврежденной файловой системе, вы рискуете привести ядро в паническое состояние. Все проверки и восстановления выполняются на демонтированной или неиспользуемой файловой системе. Если в настоящий момент файловая система смонтирована, fsck не начинает ее проверку.

В большинстве случаев при повреждении файловой системы нарушается связь между самими файлами и их именами. Это возможно потому, что в системе UNIX имена файлов хранятся в каталогах, а остальная информация – в индексных дескрипторах файлов. Файлы без имен называют файлами–сиротами, и программа fsck пытается поместить их в каталог по имени «lost+found» (потерянные + найденные).

Поэтому прежде чем выполнять программу, вы должны создать такой каталог в корне файловой системы, и завести в нем свободные элементы (для этого в «lost+found» следует скопировать несколько файлов, а затем удалить их). Если каталога «lost+found» нет, то файлы–сироты будут уничтожены. При их регистрации в каталоге программа fsck использует числа в качестве имен, совпадающие с номерами их индексных дескрипторов. Вы можете восстановить действительное имя файла по его содержимому, а затем возвратить его владельцу.

В последних версиях ОС Solaris при создании файловой системы в ней сразу создается каталог lost+found. Это делается для того, чтобы при автоматическом восстановлении файлов после сбоя (при перезагрузке, например) программе fsck было куда записать потерявшиеся фрагменты файлов.

В последних версиях OC UNIX появилась программа fsdb, служащая для отладки файловой системы и реализующая более тонкие методы ее восстановления. С этой программой может работать лишь тот, кто хорошо понимает файловую структуру.