Добавлен: 29.10.2018
Просмотров: 48116
Скачиваний: 190
346
Глава 4. Файловые системы
Когда в таблице открытых файлов делается новая запись, в нее включается указатель на
запись квоты владельца, облегчающий поиск различных лимитов. При каждом добав-
лении блока к файлу увеличивается общее число блоков, числящихся за владельцем,
и оно сравнивается как с назначаемым, так и с жестким лимитом. Назначаемый лимит
может быть превышен, а вот жесткий лимит — нет. Попытка добавить что-нибудь
к файлу, когда достигнут жесткий лимит, приведет к ошибке. Аналогичные сравнения
проводятся и для количества файлов, чтобы запретить пользователю дробление i-узлов.
Когда пользователь пытается зарегистрироваться, система проверяет квоту файлов
на предмет превышения назначенного лимита как по количеству файлов, так и по
количеству дисковых блоков. Когда какой-либо из лимитов превышен, выводится
предупреждение и счетчик оставшихся предупреждений уменьшается на единицу.
Если когда-нибудь счетчик дойдет до нуля, это значит, что пользователь сразу проиг-
норировал слишком много предупреждений и ему не будет предоставлена возможность
зарегистрироваться. Для повторного разрешения на регистрацию пользователю нужно
будет обращаться к системному администратору.
У этого метода есть особенность, которая позволяет пользователям превысить на-
значенные им лимиты в течение сеанса работы при условии, что они ликвидируют
превышение перед выходом из системы. Жесткий лимит не может быть превышен ни
при каких условиях.
4.4.2. Резервное копирование файловой системы
Выход из строя файловой системы зачастую оказывается куда более серьезной непри-
ятностью, чем поломка компьютера. Если компьютер ломается из-за пожара, удара
молнии или чашки кофе, пролитой на клавиатуру, это, конечно же, неприятно и ведет
к непредвиденным расходам, но обычно дело обходится покупкой новых комплектую-
щих и не причиняет слишком много хлопот
1
. Если же на компьютере по аппаратной или
программной причине будет безвозвратно утрачена его файловая система, восстановить
всю информацию будет делом нелегким, небыстрым и во многих случаях просто невоз-
можным. Для людей, чьи программы, документы, налоговые записи, файлы клиентов,
базы данных, планы маркетинга или другие данные утрачены навсегда, последствия
могут быть катастрофическими. Хотя файловая система не может предоставить какую-
либо защиту против физического разрушения оборудования или носителя, она может
помочь защитить информацию. Решение простое: нужно делать резервные копии. Но
проще сказать, чем сделать. Давайте ознакомимся с этим вопросом.
Многие даже не задумываются о том, что резервное копирование их файлов стоит по-
траченного на это времени и усилий, пока в один прекрасный день их диск внезапно
не выйдет из строя, — тогда они клянут себя на чем свет стоит. Но компании (обычно)
прекрасно осознают ценность своих данных и в большинстве случаев делают резервное
копирование не реже одного раза в сутки, чаще всего на ленту. Современные ленты со-
держат сотни гигабайт, и один гигабайт обходится в несколько центов. Несмотря на это
создание резервной копии — не такое уж простое дело, поэтому далее мы рассмотрим
ряд вопросов, связанных с этим процессом.
1
Следует заметить, что в случае пожара или удара молнии возможна и обратная ситуация
с очень большими хлопотами (из-за утраты данных или физической утраты самого компью-
тера), причем даже на значительном расстоянии от места происшествия. — Примеч. ред.
4.4. Управление файловой системой и ее оптимизация
347
Резервное копирование на ленту производится обычно для того, чтобы справиться
с двумя потенциальными проблемами:
восстановлением после аварии;
восстановлением после необдуманных действий (ошибок пользователей).
Первая из этих проблем заключается в возвращении компьютера в строй после по-
ломки диска, пожара, наводнения или другого стихийного бедствия. На практике такое
случается нечасто, поэтому многие люди даже не задумываются о резервном копирова-
нии. Эти люди по тем же причинам также не склонны страховать свои дома от пожара.
Вторая причина восстановления вызвана тем, что пользователи часто случайно удаля-
ют файлы, потребность в которых в скором времени возникает опять. Эта происходит
так часто, что когда файл «удаляется» в Windows, он не удаляется навсегда, а просто
перемещается в специальный каталог — Корзину, где позже его можно отловить и легко
восстановить. Резервное копирование делает этот принцип более совершенным и дает
возможность файлам, удаленным несколько дней, а то и недель назад, восстанавливать-
ся со старых лент резервного копирования.
Резервное копирование занимает много времени и пространства, поэтому эффектив-
ность и удобство играют в нем большую роль. В связи с этим возникают следующие
вопросы. Во-первых, нужно ли проводить резервное копирование всей файловой
системы или только какой-нибудь ее части? Во многих эксплуатирующихся компью-
терных системах исполняемые (двоичные) программы содержатся в ограниченной
части дерева файловой системы. Если все они могут быть переустановлены с веб-сайта
производителя или установочного DVD-диска, то создавать их резервные копии нет
необходимости. Также у большинства систем есть каталоги для хранения временных
файлов. Обычно включать их в резервную копию также нет смысла. В UNIX все спе-
циальные файлы (устройства ввода-вывода) содержатся в каталоге
/dev
. Проводить
резервное копирование этого каталога не только бессмысленно, но и очень опасно, по-
скольку программа резервного копирования окончательно зависнет, если попытается
полностью считать его содержимое. Короче говоря, желательно проводить резервное
копирование только указанных каталогов со всем их содержимым, а не копировать
всю файловую систему.
Во-вторых, бессмысленно делать резервные копии файлов, которые не изменились со
времени предыдущего резервного копирования, что наталкивает на мысль об инкре-
ментном резервном копировании
. Простейшей формой данного метода будет перио-
дическое создание полной резервной копии, скажем, еженедельное или ежемесячное,
и ежедневное резервное копирование только тех файлов, которые были изменены со
времени последнего полного резервного копирования. Еще лучше создавать резервные
копии только тех файлов, которые изменились со времени их последнего резервного
копирования. Хотя такая схема сводит время резервного копирования к минимуму,
она усложняет восстановление данных, поскольку сначала должна быть восстановлена
самая последняя полная резервная копия, а затем в обратном порядке все сеансы инкре-
ментного резервного копирования. Чтобы упростить восстановление данных, зачастую
используются более изощренные схемы инкрементного резервного копирования.
В-третьих, поскольку обычно резервному копированию подвергается огромный объ-
ем данных, может появиться желание сжать их перед записью на ленту. Но у многих
алгоритмов сжатия одна сбойная область на ленте может нарушить работу алгоритма
распаковки и сделать нечитаемым весь файл или даже всю ленту. Поэтому, прежде
348
Глава 4. Файловые системы
чем принимать решение о сжатии потока резервного копирования, нужно хорошенько
подумать.
В-четвертых, резервное копирование активной файловой системы существенно за-
труднено. Если в процессе резервного копирования происходит добавление, удаление
и изменение файлов и каталогов, можно получить весьма противоречивый результат.
Но поскольку архивация данных может занять несколько часов, то для выполнения
резервного копирования может потребоваться перевести систему в автономный режим
на большую часть ночного времени, что не всегда приемлемо. Поэтому были разрабо-
таны алгоритмы для создания быстрых копий текущего состояния файловой системы
за счет копирования критических структур данных, которые при последующем изме-
нении файлов и каталогов требуют копирования блоков вместо обновления их на месте
(Hutchinson et al., 1999). При этом файловая система эффективно «замораживается»
на момент создания быстрой копии текущего состояния, и ее резервная копия может
быть сделана чуть позже в любое удобное время.
И наконец, в-пятых, резервное копирование создает для организации множество
нетехнических проблем. Самая лучшая в мире постоянно действующая система без-
опасности может оказаться бесполезной, если системный администратор хранит все
диски или ленты с резервными копиями в своем кабинете и оставляет его открытым
и без охраны, когда спускается в зал за распечаткой. Шпиону достаточно лишь войти
на несколько секунд, положить в карман одну небольшую кассету с лентой или диск
и спокойно уйти прочь. Тогда с безопасностью можно будет распрощаться. Ежеднев-
ное резервное копирование вряд ли пригодится, если огонь, охвативший компьютер,
испепелит и ленты резервного копирования. Поэтому диски резервного копирования
должны храниться где-нибудь в другом месте, но это повышает степень риска (по-
скольку теперь нужно позаботиться о безопасности уже двух мест). Более подробно
этот и другие проблемы администрирования рассмотрены в работе Немета (Nemeth
et al., 2000). Далее обсуждение коснется только технических вопросов, относящихся
к резервному копированию файловой системы.
Для резервного копирования диска можно воспользоваться одной из двух стратегий:
физической или логической архивацией. Физическая архивация ведется с нулевого
блока диска, при этом все дисковые блоки записываются на лету в порядке их следо-
вания и, когда скопирован последний блок, запись останавливается. Эта программа
настолько проста, что, возможно, она может быть избавлена от ошибок на все 100 %,
чего, наверное, нельзя сказать о любых других полезных программах.
Тем не менее следует сделать несколько замечаний о физической архивации. Прежде
всего, создавать резервные копии неиспользуемых дисковых блоков не имеет никакого
смысла. Если программа архивирования может получить доступ к структуре данных,
регистрирующей свободные блоки, она может избежать копирования неиспользуемых
блоков. Но пропуск неиспользуемых блоков требует записывать номер блока перед
каждым из них (или делать что-нибудь подобное), потому что теперь уже не факт, что
блок k на резервной копии был блоком k на диске.
Вторая неприятность связана с архивированием дефектных блоков. Создать диски
больших объемов без каких-либо дефектов практически невозможно. На них всегда
найдется несколько дефектных блоков. Время от времени при низкоуровневом форма-
тировании дефектные блоки выявляются, помечаются как плохие и подменяются за-
пасными блоками, находящимися на всякий случай в резерве в конце каждой дорожки.
4.4. Управление файловой системой и ее оптимизация
349
Во многих случаях контроллер диска справляется с плохими блоками самостоятельно,
и операционная система даже не знает об их существовании.
Но иногда блоки портятся уже после форматирования, что когда-нибудь будет об-
наружено операционной системой. Обычно эта проблема решается операционной
системой путем создания «файла», в котором содержатся все плохие блоки. Это
делается хотя бы для того, чтобы они никогда не попали в пул свободных блоков
и никогда не попали под распределение. Наверное, излишне говорить, что эти файлы
абсолютно нечитаемы.
Если, как говорилось ранее, все плохие блоки перераспределены контроллером дис-
ка и скрыты от операционной системы, то физическое архивирование проходит без
проблем. Однако если такие блоки находятся в поле зрения операционной системы
и собраны в один или несколько файлов или битовых массивов, то очень важно, чтобы
программа, осуществляющая физическое архивирование, имела доступ к этой ин-
формации и избегала архивирования этих блоков, чтобы предотвратить бесконечные
ошибки чтения диска при попытках сделать резервную копию файла, состоящего из
плохих блоков.
У систем Windows имеются файлы подкачки и гибернации, которые не нуждаются
в восстановлении и не должны подвергаться резервному копированию в первую
очередь. У конкретных систем могут иметься и другие внутренние файлы, которые
не должны подвергаться резервному копированию, поэтому программы архивации
должны о них знать.
Главным преимуществом физического архивирования являются простота и высокая
скорость работы (в принципе, архивирование может вестись со скоростью работы дис-
ка). А главным недостатком является невозможность пропуска выбранных каталогов,
осуществления инкрементного архивирования и восстановления по запросу отдельных
файлов. Исходя из этого в большинстве эксплуатирующихся компьютерных систем
проводится логическое архивирование.
Логическая архивация
начинается в одном или нескольких указанных каталогах и ре-
курсивно архивирует все найденные там файлы и каталоги, в которых произошли из-
менения со времени какой-нибудь заданной исходной даты (например, даты создания
резервной копии при инкрементном архивировании или даты установки системы для
полного архивирования). Таким образом, при логической архивации на магнитную ленту
записываются последовательности четко идентифицируемых каталогов и файлов, что
упрощает восстановление по запросу указанного файла или каталога.
Поскольку наибольшее распространение получила логическая архивация, рассмо-
трим подробности ее общего алгоритма на основе примера (рис. 4.21). Этот алгоритм
используется в большинстве UNIX-систем. На рисунке показана файловая система
с каталогами (квадраты) и файлами (окружности). Закрашены те элементы, которые
подверглись изменениям со времени исходной даты и поэтому подлежат архивирова-
нию. Светлые элементы в архивации не нуждаются.
Согласно этому алгоритму архивируются также все каталоги (даже не подвергшиеся
изменениям), попадающиеся на пути к измененному файлу или каталогу, на что было
две причины. Первая — создать возможность восстановления файлов и каталогов из
архивной копии в только что созданной файловой системе на другом компьютере.
Таким образом, архивирование и восстановление программ может быть использовано
для переноса всей файловой системы между компьютерами.
350
Глава 4. Файловые системы
Второй причиной архивирования неизмененных каталогов, лежащих на пути к из-
мененным файлам, является возможность инкрементного восстановления отдельного
файла (например, чтобы восстановить файл, удаленный по ошибке). Предположим,
что полное архивирование файловой системы сделано в воскресенье вечером, а ин-
крементное архивирование сделано в понедельник вечером. Во вторник каталог
/usr/
jhs/proj/nr3
был удален вместе со всеми находящимися в нем каталогами и файлами.
В среду спозаранку пользователю захотелось восстановить файл
/usr/jhs/proj/nr3/plans/
summary
. Но восстановить файл
summary
не представляется возможным, поскольку его
некуда поместить. Сначала должны быть восстановлены каталоги
nr3
и
plans
. Чтобы
получить верные сведения об их владельцах, режимах использования, метках времени
и других атрибутах, эти каталоги должны присутствовать на архивном диске, даже
если сами они не подвергались изменениям со времени последней процедуры полного
архивирования.
Рис. 4.21. Архивируемая файловая система. Квадратами обозначены каталоги,
а окружностями — файлы. Закрашены те элементы, которые были изменены со времени
последнего архивирования. Каждый каталог и файл помечен номером своего i-узла
Согласно алгоритму архивации создается битовый массив, проиндексированный по
номеру i-узла, в котором на каждый i-узел отводится несколько битов. При реализации
алгоритма эти биты будут устанавливаться и сбрасываться. Реализация проходит в че-
тыре этапа. Первый этап начинается с исследования всех элементов начального каталога
(например, корневого). В битовом массиве помечается i-узел каждого измененного
файла. Также помечается каждый каталог (независимо от того, был он изменен или нет),
а затем рекурсивно проводится аналогичное исследование всех помеченных каталогов.
В конце первого этапа помеченными оказываются все измененные файлы и все ката-
логи, что и показано закрашиванием на рис. 4.22, а. Согласно концепции на втором
этапе происходит повторный рекурсивный обход всего дерева, при котором снимаются
пометки со всех каталогов, которые не содержат измененных файлов или каталогов