Операционные системы 2011 (1114689), страница 57

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 57)

Еслифайловая система предоставляет возможность квотировать размер блока, то надоучитывать, что больший размер блока ведет к увеличению производительности файловойсистемы (поскольку данные файла оказываются локализованными на жестком диске, изчего следует, что при доступе снижается количество перемещений считывающейголовки). Но недостатком является то, что чем больше размер блока, тем вышевнутренняя фрагментация, а, следовательно, возникает неэффективность использованияпространства ВЗУ (если, блок имеет размер, например, 1024 байт, а файл занимает 1 байт,то теряются 1023 байта).

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

номера свободных блоков образуют связный список,210который располагается в нескольких блоках файловой системы. Для более эффективнойработы первый блок, содержащий начальную часть списка, должен располагаться в ОЗУ,чтобы файловая система могла к нему оперативно обращаться. Заметим, что список можетдостигать больших размеров: если размер блока 1 Кбайт, т.е. его можно представить ввиде 256 четырехбайтных слов, то такой блок может содержать в себе 255 номеровсвободных блоков и одну ссылку на следующий блок со списком, тогда для жесткогодиска, емкостью 16 Гбайт, потребуется 16794 блока.

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

Заметим, что операция пересчета достаточно трудоемка, к тому же эта модельтребует выделения под массив стационарного ресурса: так, для 16-ти гигабайтногожесткого диска потребуется 2048 блоков для хранения битового массива.4.1.9 Квотирование пространства файловой системыКак отмечалось выше, файловая система должна обеспечивать контрольиспользования двух видов системных ресурсов — это регистрация файлов в каталогах(т.е. контроль количества имен файлов, которое можно зарегистрировать в каталоге) иконтроль свободного пространства (чтобы не возникла ситуация, когда один процессзаполнил все свободное пространство, тем самым не давая другим пользователямвозможность сохранять свои данные).

Для решения поставленных задач в файловойсистеме вводятся квотирование имен (т.е. числа) файлов и квотирование блоков(Рис. 113).В общем случае модель квотирования может иметь два типа лимитов: жесткий игибкий. Для каждого пользователя при его регистрации в системе определяются два типаквот. Жесткий лимит — это количество имен в каталогах или количество блоковфайловой системы, которое пользователь превзойти не может: если происходитпревышение жесткого лимита, работа пользователя в системе блокируется. Гибкийлимит — это значение, которое устанавливается в виде лимита; с ним ассоциировано ещеодно значение, называемое счетчиком предупреждений (гибкий лимит превышатьможно, но после этого включается обратный счётчик предупреждений). При входепользователя в систему происходит подсчет соответствующего ресурса (числа именфайлов либо количества используемых пользователем блоков файловой системы).

Есливычисленное значение не превосходит гибкий лимит, то счетчик предупрежденийсбрасывается на начальное значение, и пользователь продолжает свою работу. Если жевычисленное значение превосходит установленный гибкий лимит, то значение счетчикапредупреждений уменьшается на единицу, затем происходит проверка равенства егозначения нулю. Если значение счётчика равно нулю, то вход пользователя в системублокируется, иначе (если значение больше нуля) пользователь получает предупреждениео том, что соответствующий гибкий лимит израсходован, после чего пользователь можетработать дальше. Таким образом, система позволяет пользователю привести свое«файловое пространство» в порядок в соответствии с установленными квотами.211Гибкий лимит блоковУчет использованияквот на блокиЖесткий лимит блоковИспользовано блоковСчетчик предупрежденийГибкий лимит числа файловУчет использованияквот на число файловЖесткий лимит числа файловИспользовано файловСчетчик предупрежденийРис.

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

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

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

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

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

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

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

Альтернативой физическому копированию является логическаяархивация. Эта стратегия подразумевает копирование не блоков, а файлов (например,файлов, модифицированных после заданной даты).4.1.11 Проверка целостности файловой системыДалее речь пойдет о моделях организации контроля и исправления ошибочныхситуаций, связанных с целостностью файловой системы. Обратим внимание, что будетрассматриваться целостность именно файловой системы, а не файлов. Если произошелсбой (например, сломался центральный процессор или оперативная память), тогарантированно потери будут, и эти потери будут двух типов. Во-первых, это потеряактуального содержимого одного или нескольких открытых файлов.

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

Характеристики

Список файлов лекций