Файловые системы. Лекция 6 Файловая система, ввод и вывод информации. Вводвывод и файловая система 1 Задачи ос по управлению файлами и устройствами
 Скачать 0.51 Mb.
|
4.1. Устойчивость ФС к сбоям дискаПростые ФС Кроме общесистемных сбоев, ФС должна обеспечивать средства восстановления при физических сбоях диска. Наиболее распространенным видом таких сбоев являются нечитаемые – «плохие» (bad) – блоки, появление которых обычно связано с физическими дефектами магнитного носителя. Жесткие магнитные диски помещены в герметичный корпус и – в норме – не соприкасаются с головками дисковода, поэтому срок службы таких дисков много больше. Появление одиночных плохих блоков на жестком диске скорее всего свидетельствует о заводском дефекте поверхности или же о том, что магнитный слой от старости начал деградировать. Весьма опасной причиной порчи жестких дисков является соприкосновение головок чтения/записи с поверхностью вращающегося диска (head crash), например, из-за чрезмерно сильных сотрясений диска во время работы. В частности, из-за этого не следует переставлять работающие компьютеры, особенно во время активных операций с диском. Обычно такое соприкосновение приводит к повреждению целой дорожки или нескольких дорожек диска, а зачастую и самой головки. Для несъемных жестких дисков это не редко означает потерю целой рабочей поверхности: считывание данных с нее требует замены блока головок, что весьма дорого. Обычно ошибки данных обнаруживаются при чтении. Дисковые контроллеры используют при записи кодировку с исправлением ошибок, чаще всего коды Хэмминга, которые позволяют обнаруживать и исправлять ошибки. Тем не менее, если при чтении была выявлена ошибка, большинство ОС отмечают такой блок как плохой, даже если удалось восстановить его на основании избыточного кода. В файловой системе FAT плохой блок или кластер, содержащий такой блок, отмечается кодом 0xFFFB (с 16-разрядной FAT). Эта файловая система не способна компенсировать плохие блоки в самой FAT или в корневом каталоге диска. Такие диски просто считаются непригодными для использования. Сложные ФС В «сложных» файловых системах обычно используется более сложный, но зато и более удобный способ обхода плохих блоков, называемый горячей заменой (hotfixing). При создании файловой системы отводится небольшой пул блоков, предназначенных для горячей замены. В файловой системе хранится список всех обнаруженных плохих блоков, и каждому такому блоку поставлен в соответствие блок из пула горячей замены. При этом плохие блоки, на которые оказались отображены системные структуры данных, например участок таблицы инодов, также подвергается горячей замене. Таблица горячей замены может быть как статической, так и динамической. На первый взгляд, динамическая таблица горячей замены предпочтительна, однако не нужно забывать о двух немало важных факторах: Файловая система вынуждена использовать для справки таблицу горячей замены при всех обращениях к диску, поэтому увеличение таблицы приводит к замедлению работы. Множественные плохие блоки на жестком диске свидетельствуют либо о том, что диск дефективный, либо о том, что магнитный слой начал разрушаться от старости (иными словами, что этот диск пора выбрасывать), либо о каких-то других не менее серьезных проблемах, вроде разгерметизации корпуса и проникновения в него пыли. С учетом обоих факторов кажется целесообразным установить предел количества плохих блоков, после достижения которого диск нуждается в замене. Следует отметить также, что этот предел не может превышать нескольких процентов общей емкости диска. В свете этого небольшая статическая таблица блоков горячей замены представляется вовсе не такой уж плохой идеей. Современные контроллеры жестких дисков часто предоставляют свои средства горячей замены блоков, происходящие незаметно для центрального процессора. 5.2. Восстановление ФС после сбояЧаще всего суперблок неустойчивых ФС содержит флаг durty («грязный»), сигнализирующий о том, что ФС, возможно, нуждается в восстановлении. Этот флаг сбрасывается при нормальном размонтировании ФС и устанавливается при ее монтировании или при модификации после монтирования. Таким образом, если ОС погибла, не успев размонтировать свои дисковые тома, после перезагрузки на этих томах durty-флаг будет установлен, что и станет сигналом необходимости починки. Восстановление состоит в том, что система проверяет пространство, выделенное всем файлам. При этом должны выполняться следующие требования: Каждая запись в каталоге должна иметь правильный формат и содержать осмысленные данные. Например, если запись помечена как свободная, она не должна ссылаться на данные, помеченные как принадлежащие файлу, или на инод. Не во всех ФС можно обнаружить ошибки такого типа. Каждый блок или кластер диска должен принадлежать не более, чем одному файлу. Блоки, принадлежащие одновременно двум или более файлам, являются очень серьезной ошибкой. На практике это означает, что данные во всех этих файлах (в лучшем случае – во всех, кроме того, запись в который была последней) безнадежно испорчены. Чаще всего программа восстановления в этой ситуации требует вмешательства пользователя, с тем чтобы решить, какие из файлов следует удалить или обрезать по месту пересечения. Иногда для каждого из файлов создается копия «общего» блока, но и в этом случае пользователю все равно нужно определить, какие из файлов испорчены. Практически все ФС при выделении блока сначала удаляют его из списка свободных и лишь потом отдают файлу, поэтому при «обычных» сбоях перекрещивание файлов возникнуть может только как следствие отложенной записи в сочетании с сортировкой запросов. Возникновение таких ошибок обычно сигнализирует либо об ошибке в самом файловом менеджере, либо об аппаратных сбоях на диске, либо о том, что структуры ФС были модифицированы в обход файлового менеджера. Например, это может быть признаком вирусной активности. Каждому файлу должно быть выделено пространство, соответствующее его длине. Если файлу выделено больше блоков, чем требуется, лишение блоки помечаются как свободные. Если меньше, файл укорачивается. Возможно, в укороченных файлах часть данных оказывается потеряна. Все блоки, не принадлежащие файлам, должны быть помечены, как свободные. Соответствующий тип ошибок – потерянные блоки – наиболее частый результат системных сбоев как в файловой системе FAT, так и в более сложных файловых системах. Сами по себе ошибки этого типа относительно безобидны. Обычно программа восстановления не помечает потерянные блоки как свободные, выделяет из них непрерывные цепочки и создает из этих цепочек файлы. В DOS эти файлы помещаются в корневой каталог ФС под именами FILEXXXX.CHK (вместо XXXX подставляется номер). Предполагается, что пользователь просматривает все такие файлы и определяет, не содержит ли какой-то из них ценной информации, например, конца насильственного укороченного файла. В системах семейства Unix существует несколько специфических ошибок, связанных с инодами: Инод, внутренний счетчик ссылок которого не соответствует реальному количеству ссылок из каталогов. Эта проблема может возникать при системном сбое в момент удаления существовавшей связи или создания новой. Она решается коррекцией внутреннего счетчика инода. После этого можно обнаружить следующие две ошибки. Инод, не имеющий ни одной ссылки, но и не помеченный как свободный – сирота (orphan) Ссылка на такой инод создается в каталоге lost + found; Инод с ненулевым количеством ссылок из каталогов, но помеченный как свободный. Чаще всего это свидетельствует о порче самого каталога. Обычно ссылки на такой инод удаляются. 4.3. Файловые системы с регистрацией намеренийВо многих современных ОС реализованы устойчивые к сбоям файловые системы: Veritas в UnixWare, NTFS в Windows NT/2000/XP и т.д.. Практически все такие ФС основаны на механизме, который по-английски называется intention logging (журнал, регистрация намерений). Идея журналов регистрации намерений пришла из систем управления базами данных. В СУБД часто возникает задача внесения согласованных изменений в несколько разных структур данных. Например, банковская система переводит миллион долларов с одного счета на другой. СУБД вычитает 1 000 000 из суммы на первом счету, затем пытается добавить ту же величину ко второму счету и в этот момент происходит сбой. Для СУБД этот пример выглядит очень тривиально, но он похож на ситуацию в файловой системе: в каком бы порядке ни производились действия по переносу объекта из одной структуры в другую, сбой в неудачный момент приводит к крайне неприятной ситуации. В СУБД эта проблема была осознана как острая очень давно – ведь миллион долларов всегда был намного дороже одного сектора на диске. Предварительное решение проблемы заключается в следующем: Во-первых, все согласованные изменения в СУБД организуются в блоки, называемые транзакциями (transaction). Каждая транзакция осуществляется как неделимая (атомарная) операция, во время которой никакие другие операции над изменяемыми данными не разрешены. Во-вторых, каждая транзакция осуществляется в три этапа (рис. 21). система записывает в специальный журнальный файл, что же она собирается делать. если запись в журнал была успешной, система выполняет транзакцию. если транзакция завершилась нормально, система помечает в журнале, что намерение было успешно реализовано. Журнал часто называют журналом регистрации намерений(intention log), что очень хорошо отражает суть дела, потому что в этот журнал записываются именно намерения (intentions). При использовании отложенной записи транзакция считается полностью завершенной, только когда последний блок измененных данных будет физически записан на диск. При этом в системе обычно будет одновременно существовать несколько незавершенных транзакций. Легко понять, что при операциях с самим журналом отложенную запись вообще нельзя использовать. Если произошел сбой системы, после перезагрузки запускается программа восстановления базы данных. Эта программа просматривает конец журнала: если она видит там испорченную запись, то игнорирует ее: сбой произошел во время записи в журнал. если все записи помечены как успешно выполненные транзакции, то сбой произошел между транзакциями: ничего особенного не случилось; во всяком случае, ничего исправлять не надо. если найденная запись, которая отмечает начатую, но невыполненную транзакцию, то сбой произошел во время этой транзакции. Это наиболее неприятная ситуация, но журнал содержит достаточно информации для того, чтобы или восстановить состояние базы данных до начала транзакции (выполнить откат назад (rollback)), или же доделать предполагавшиеся изменения. Нужно отметить, что данные, необходимые для выполнения отката, могут иметь большой объем. Фактически это копия всех данных, подвергающихся изменению в ходе транзакции. Многие СУБД, такие как ORACLE, хранят эти данные не в самом журнале, а в специальной области данных, называемой сегмент отката(rollback segment). Идея журнала намерений достаточно естественно переносится в программу управления файловой системой. Но здесь возникает интересный вопрос – что же считать транзакцией: только операции по распределению пространства на диске или также все операции по изменению данных? Первый вариант проще в реализации и оказывает меньшее влияние на производительность; зато он гарантирует только целостность самой ФС, но не может гарантировать целостности пользовательских данных, если сбой произойдет в момент записи в файл. Второй вариант требует выделения сегмента отката и сильно замедляет работу. Действительно, ведь теперь данные пишутся на диск два раза: сначала в сегмент отката, а потом в сам файл. Зато он существенно снижает вероятность порчи пользовательских данных. Ряд современных ФС с регистрацией намерений поддерживают оба режима работы и предоставляют выбор между этими вариантами администратору системы. |