I. Элементы архитектуры вычислительных систем

Вид материала

Документы

Содержание Восстановление ФС после сбоя Файловые системы с трассировкой транзакций Устойчивость ФС к сбоям диска.

Подобный материал:

• Опд. Ф. 11 «Сети ЭВМ и Телекоммуникации», 48.27kb.
• Классификация элементов вычислительных средств, 641.33kb.
• Вопросы на экзамен по дисциплине «Архитектура вычислительных систем» (авс), 29kb.
• Архитектура Вычислительных Систем», Университет «Дубна» лекция, 193.82kb.
• Высшего Профессионального Образования Современная Гуманитарная Академия утверждаю ректор, 120.08kb.
• Учебная программа по дисциплине основы технической эксплуатации и защиты вычислительных, 119.22kb.
• Вдокладе рассмотрены современные архитектурные принципы и методы реализации перспективных, 34.3kb.
• Реферат: Вработе рассматривается среда моделирования распределенных многопроцессорных, 93.04kb.
• Программное обеспечение вычислительных систем и сетей, 257.78kb.
• Архитектура Вычислительных Систем», Университет «Дубна» лекция, 144.31kb.

Свойство устойчивости к сбоям питания (power-fault tolerance) является одной из важных характеристик файловой системы. Строго говоря, имеется в виду устойчивость не только к сбоям питания, но и к любой ситуации, при которой работа с ФС прекращается без выполнения операции размонтирования. Неожиданное прекращение работы с ФС может произойти не только при сбое питания, но и при:

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

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

Хотя первая из перечисленных выше причин - извлечение носителя из дисковода - не является "сбоем" даже в самом широком смысле этого слова, с точки зрения ФС это мало чем отличается от сбоя. Поэтому на удаляемых носителях, таких, как дискеты, можно использовать только устойчивые ФС.

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

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

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

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

Упоминавшаяся выше "врожденная" устойчивость к сбоям файловой системы FAT объясняется тем, что в этой ФС удаление блока из списка свободных и выделение его файлу производится одним действием - модификацией элемента FAT. Поэтому если во время этой процедуры произойдет сбой или дискета будет вынута из дисковода, то ничего страшного не случится: просто получится файл, которому выделено на один блок больше, чем его длина, записанная в каталоге. При стирании этого файла все его блоки будут помечены как свободные, поэтому вреда практически нет.

Нужно отметить, что при использовании отложенной записи FAT и родственные ФС теряют это преимущество. При этом отложенная запись FAT является единственным способом добиться хоть сколько-нибудь приемлемой производительности от ФС с 32-битовым FAT. Поэтому, например, хотя Novell NetWare и использует ФС, основанную на 32-битной FAT, после аварийной перезагрузки эта система вынуждена запускать программу аварийной починки дисковых томов. Аналогичным образом ведет себя и 32-битная версия ДОСовской ФС FAT32.

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

Первая ситуация достаточно неприятна, вторая же просто недопустима: первый же файл, созданный после перезапуска системы, будет "перекрещиваться" с испорченным. Поэтому все ОС, использующие файловые системы такого типа (системы семейства Unix, OS/2, Windows NT и т.д.), после аварийной перезагрузки первым делом проверяют свои ФС соответствующей программой починки.

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

Восстановление ФС после сбоя

Чаще всего суперблок неустойчивых ФС содержит флаг dirty ("грязный"), сигнализирующий о том, что ФС, возможно, нуждается в починке. Этот флаг сбрасывается при нормальном размонтировании ФС и устанавливается при ее монтировании или при первой модификации после монтирования.

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

1. Каждая запись в каталоге должна иметь правильный формат и содержать осмысленные данные. Например, если запись помечена как свободная, она не должна ссылаться на данные, помеченные как принадлежащие файлу, или на инод. Не во всех ФС можно обнаружить ошибки такого типа.
   
2. Каждый блок или кластер диска должен принадлежать не более, чем одному файлу. Блоки, принадлежащие одновременно двум или более файлам, являются очень серьезной ошибкой. Чаще всего программа починки в этой ситуации требует вмешательства пользователя, с тем чтобы решить, какие из файлов следует удалить или обрезать по месту пересечения. Иногда для каждого из файлов создается копия "общего" блока. Практически все ФС при выделении блока сначала удаляют его из списка свободных и лишь потом отдают файлу, поэтому при "обычных" сбоях перекрещивание файлов возникнуть может только как следствие отложенной записи в сочетании с сортировкой запросов. Возникновение таких ошибок обычно сигнализирует либо об ошибке в самом файловом менеджере, либо об аппаратных сбоях на диске, либо о том, что структуры ФС были модифицированы в обход файлового менеджера. Например, в ДОС это может быть признаком вирусной активности.
   
3. Каждому файлу должно быть выделено пространство, соответствующее его длине. Если файлу выделено больше блоков, чем требуется, лишние блоки помечаются как свободные. Если меньше, файл укорачивается. Возможно, в укороченных файлах часть данных оказывается потеряна.
   
4. Все блоки, не принадлежащие файлам, должны быть помечены, как свободные. Соответствующий тип ошибок - потерянные блоки - наиболее частый результат системных сбоев как в файловой системе FAT, так и в более сложных файловых системах. Сами по себе ошибки этого типа относительно безобидны. Обычно программа починки не помечает потерянные блоки как свободные, а выделяет из них непрерывные цепочки и создает из этих цепочек файлы. Например, в DOS эти файлы помещаются в корневой каталог ФС под именами FILEXXXX.CHK (вместо XXXX подставляется номер). Предполагается, что пользователь просматривает все такие файлы и определяет, не содержит ли какой-то из них ценной информации, например конца насильственно укороченного файла.
   
5. В системах семейства Unix существует несколько специфических ошибок, связанных с инодами:
   
   • инод, внутренний счетчик ссылок которого не соответствует реальному количеству ссылок из каталогов. Эта проблема может возникать при системном сбое в момент удаления существовавшей связи или создания новой. Она решается коррекцией внутреннего счетчика инода. После этого можно обнаружить следующие две ошибки;
     
   • инод, не имеющий ни одной ссылки, но не помеченный как свободный - сирота (orphan). Ссылка на такой инод создается в каталоге lost+found;
     
   • инод с ненулевым количеством ссылок из каталогов, но помеченный свободным. Чаще всего это свидетельствует о порче самого каталога. Обычно ссылки на такой инод удаляются.
     

Файловые системы с трассировкой транзакций

Во многих современных ОС реализованы устойчивые к сбоям файловые системы: jfs в AIX(версия Unix, поставляемая IBM), Merlin), Veritas в UnixWare, NTFS в Windows NT. Практически все такие ФС основаны на механизме, который по-английски называется intention logging (регистрация намерений) или, в некоторых системах - transaction tracing (трассировка транзакций).

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

Во-первых, все согласованные изменения в СУБД организуются в блоки, называемые транзакциями (transaction). Каждая транзакция осуществляется как неделимая (атомарная) операция, во время которой никакие другие операции над изменяемыми данными не разрешены.

Во-вторых, каждая транзакция осуществляется в три этапа:

1. <Система записывает в специальный журнальный файл информацию о планируемой операции над данными.
   
2. Если запись в журнал была успешной, система выполняет транзакцию.
   
3. Если транзакция завершилась нормально, система помечает в журнале, что намерение было успешно реализовано.
   

Журнал часто называют журналом регистрации намерений (intention log), что очень хорошо отражает суть дела, потому что в этот журнал записываются именно намерения (intentions).

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

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

Если она видит там испорченную запись, то игнорирует ее: сбой произошел во время записи в журнал.

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

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

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

Легко понять, что идея журнала намерений достаточно естественно переносится в программу управления файловой системой. Но здесь возникает интересный вопрос - что же считать транзакцией: только операции по распределению пространства на диске или также все операции по изменению данных?

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

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

Ряд современных ФС с регистрацией намерений поддерживают оба режима работы и предоставляют выбор между этими вариантами администратору системы. Например, у файловой системы vxfs или Veritas, входящей в пакет UnixWare (версия Unix SVR4, поставляемая фирмой Novell), существует две версии. Одна версия, поставляемая вместе с системой по умолчанию, включает в транзакцию только системные данные. Другая, "advanced", версия, которая поставляется за отдельные деньги, осуществляет регистрацию намерений как для системных, так и для пользовательских данных.

Устойчивость ФС к сбоям диска.

Кроме общесистемных сбоев, ФС должна обеспечивать средства восстановления при физических сбоях диска. Наиболее распространенным видом таких сбоев являются нечитаемые - "плохие" (bad) - блоки, появление которых обычно связано с физическими дефектами магнитного носителя.

Обычно ошибки данных обнаруживаются при чтении. Дисковые контроллеры используют при записи кодировку с исправлением ошибок, чаще всего, коды типа CRC (Cyclic Redundancy Code - циклический избыточный код), которые позволяют обнаруживать и исправлять множественные ошибки. Тем не менее, если при чтении была обнаружена ошибка, большинство ОС отмечают такой блок как плохой, даже если данные удалось восстановить на основании избыточного кода.

В файловой системе FAT плохой блок или кластер, содержащий такой блок, отмечается кодом 0xFFB или 0xFFFB для дисков с 16-разрядной FAT. Эта файловая система не способна компенсировать плохие блоки в самой FAT или в корневом каталоге диска. Такие диски просто считаются непригодными для использования.

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

3.8	Пользовательский интерфейс