ОС СРС. Кэш жадысы. Кэш жадысында деректерді келісімділігі кері жне ткел жазба дістері
Скачать 304.48 Kb.
|
Что такое файловая система?Вся информация записывается на носитель в виде файлов, которые должны располагаться в определенном порядке, иначе операционная система и программы не смогут оперировать с данными. Этот порядок и организует файловая система с помощью определенных алгоритмов и правил размещения файлов на носителе. Когда программе требуется файл, записанный на диске, ей нет необходимости знать, как и где он хранится. Все, что от программы требуется – это знать имя файла, его размер и атрибуты, чтобы передать эти данные файловой системе, которая обеспечит доступ к нужному файлу. То же самое происходит и при записи данных на носитель: программа передает информацию о файле (имя, размер, атрибуты) файловой системе, которая сохраняет его по своим определенным правилам. Для лучшего понимания представьте библиотекаря, который выдает клиенту книгу по ее названию. Или в обратном порядке: клиент сдает прочитанную книгу библиотекарю, который размещает ее обратно на хранение. Клиенту совсем нет необходимости знать, где и как хранится книга, это обязанность служащего заведения. Библиотекарь знает правила каталогизации библиотеки и согласно этим правилам разыскивает издание или размещает его обратно, т.е. выполняет свои служебные функции. В данном примере библиотека – это носитель информации, библиотекарь – файловая система, клиент – программа. Основные функции файловой системыОсновными функциями файловой системы являются:
Виды файловых системВ процессе эволюции компьютеров, носителей информации и операционных систем возникало и пропадало большое количество файловых систем. В процессе такого эволюционного отбора, на сегодня для работы с жесткими дисками и внешними накопителями (флешки, карты памяти, внешние винчестеры, компакт диски) в основном используются следующие виды ФС:
Последние две системы предназначены для работы с компакт дисками. Файловые системы Ext3 и Ext4 работают с операционными системами на основе Linux. NFS Plus – это ФС для операционных систем OS X, используемых в компьютерах фирмы Apple. Файловые системы NTFS и FAT32Самое большое распространение получили файловые системы NTFS и FAT32 и это не удивительно, т.к. они предназначены для операционных систем Windows, под управлением которых работает подавляющее большинство компьютеров в мире. Сейчас FAT32 активно вытесняется более продвинутой системой NTFS по причине ее большей надежности к сохранности и защите данных. К тому же последние версии ОС Windows просто не дадут себя установить, если раздел жесткого диска будет отформатирован в FAT32. Программа установки потребует отформатировать раздел в NTFS. Файловая система NTFS поддерживает работу с дисками объемом в сотни терабайт и размером одного файла до 16 терабайт. Файловая система FAT32 поддерживает диски до 8 терабайт и размер одного файла до 4Гб. Чаще всего данную ФС используют на флешках и картах памяти. Именно в FAT32 форматируют внешние накопители на заводе. Однако ограничение на размер файла в 4Гб на сегодня уже является большим минусом, т.к. в связи с распространением высококачественного видео, размер файла с фильмом будет превышать это ограничение и его будет невозможно записать на носитель. Өзара тосқауылды модельдеу, страусты алгоритмі, өзара тосқауылды анықтау және жою В [61] показано, как можно смоделировать четыре условия взаимной блокировки, используя направленные графы. Графы имеют два вида узлов: процессы, показанные кружочками, и ресурсы, нарисованные квадратиками. Ребро, направленное от узла ресурса (квадрат) к узлу процесса (круг), означает, что ресурс ранее был запрошен процессом, получен и в данный момент используется этим процессом. На рис. 3.6, а ресурс К в настоящее время отдан процессу А. а б в Рис. 3.6. Графы распределения ресурсов: а — ресурс занят; б — запрос ресурса; в — взаимная блокировка Ребро, направленное от процесса к ресурсу, означает, что процесс в данный момент блокирован и находится в состоянии ожидания доступа к этому ресурсу. На рис. 3.6, б процесс В ждет ресурс 5. На рис. 3.6, в мы видим взаимную блокировку: процесс С ожидает ресурс Г, удерживаемый процессом £). Процесс £> вовсе не намеревается освобождать ресурс Г, потому что он ждет ресурс и, используемый процессом С. Оба процесса будут ждать до бесконечности. Цикл в графе означает наличие взаимной блокировки, циклично включающей процессы и ресурсы (предполагается, что в системе есть по одному ресурсу каждого вида). В этом примере циклом является последовательность С-7ЧО-Г/-С. Теперь рассмотрим пример того, как извлечь пользу из графов ресурсов. Представим, что у нас есть три процесса: Л, Б и С, и три ресурса: 7?, 5 и Т. Последовательность запросов и возвратов ресурсов для трех процессов показана на рис. 3.7, а-в. Операционная система может запустить любой ^заблокированный процесс в любой момент времени, значит, таковым может оказаться процесс А. Процесс А будет выполняться до тех пор, пока не закончит всю свою работу, затем запустится процесс В, а по его завершении — процесс С. Такой порядок не приводит к взаимной блокировке (не возникает соперничества за использование ресурсов), но здесь также по сути нет параллельной работы. Помимо запроса и возврата ресурсов, процессы выполняют вычисления и ввод- вывод данных. Когда процессы работают последовательно, нереальна ситуация, при которой один процесс использует процессор, в то время как другой ждет завершения операции ввода-вывода. Таким образом, строго последовательная работа процессов не бывает оптимальной. С другой стороны, если вообще ни один процесс не выполняет операций ввода-вывода, алгоритм «самое короткое задание — первое» работает эффективнее, чем циклический, поэтому в некоторых ситуациях последовательный запуск всех процессов может быть наилучшим. Теперь предположим, что процессы выполняют как вычисления, так и ввод-вывод, соответственно циклический алгоритм планирования является рациональным. Запросы ресурсов могут происходить в порядке, указанном на рис. 3.7, г. Если эти шесть запросов будут осуществлены в такой последовательности, в результате мы получим шесть графов, показанных на рис. 3.7, д-к. После запроса 4 процесс А блокируется в ожидании ресурса 5 (см. рис. 3.7, з). На двух следующих шагах также блокируются процессы Б и С, в конечном счете приводя к циклу и взаимной блокировке на рис. 3.7, к. Однако как мы упоминали ранее, операционная система не обязана запускать процессы в каком-то особом порядке. В частности, если выполнение отдельного запроса приводит к тупику, операционная система вправе просто приостановить процесс без удовлетворения запроса (то есть не выполняя план процесса) до тех пор, пока это безопасно. На рис. 3.7 операционная система могла бы приостановить процесс В вместо того, чтобы отдавать ему ресурс 5, если бы она знала о предстоящей взаимной блокировке. Работая только с процессами Л и С, мы могли бы получить такой порядок запросов ресурсов и их возвратов, который представлен на рис. 3.7, л, вместо показанного на рис. 3.7, г. Такая последовательность действий отражена графами на рис. 3.7, м-с, и она не приводит к тупику. После шага с процесс В может получить ресурс 5, потому что процесс А уже закончил свою работу, а процесс С имеет в своем распоряжении все необходимые ему ресурсы. Даже если затем процесс В, когда он запросит ресурс Г, будет заблокирован, система не зависнет. Процесс В всего лишь будет ждать завершения процесса С.
Позже в этой главе мы изучим подробный алгоритм для принятия решений о распределении ресурсов, которые не приведут к взаимной блокировке. В данный момент важно понять, что графы ресурсов являются инструментом, позволяющим увидеть, станет ли заданная последовательность запросов и возвратов ресурсов причиной тупиковой ситуации. Мы всего лишь шаг за шагом осуществляем запросы и возвраты ресурсов и после каждого шага проверяем граф на содержание циклов. Если они есть, мы оказались в тупике; если нет, значит, взаимной блокировки тоже нет. Хотя мы рассматривали графы ресурсов для случая, когда в системе присутствует по одному ресурсу каждого типа, графы также можно построить для обработки ситуации с несколькими одинаковыми ресурсами [61]. Тем не менее в [76, 77] указано на то, что в случае однородных ресурсов графы оказываются очень сложными. Если хотя бы одна ветвь графа не входит в цикл, то есть один неблокированный процесс захватывает одну из копий одного из ресурсов, взаимной блокировки не происходит. Вообще говоря, для борьбы с взаимными блокировками практикуются четыре стратегии. 1. Полное игнорирование проблемы. Если вы проигнорируете проблему, возможно, затем она проигнорирует вас. 2. Обнаружение и устранение. Взаимной блокировке позволяется произойти, затем она обнаруживается и предпринимаются те или иные действия для решения проблемы. 3. Предотвращение путем структурного избежания одного из четырех условий взаимной блокировки. 4. Динамическое избежание тупиковых ситуаций путем аккуратного распределения ресурсов. Алгоритм страуса Простейший подход - игнорировать проблему тупиков. Различные люди реагируют на подобную стратегию по-разному. Математики находят ее неприемлемой и утверждают, что тупики должны быть предотвращены любой ценой. Инженеры задают вопрос: как часто возникает данная проблема и как часто система виснет по другим причинам? Если тупик встречается раз в пять лет, но аварийный останов системы из-за отказов оборудования, ошибок компиляторов или ОС происходит раз в месяц, большинство инженеров не пожелают пожертвовать производительностью или удобством, чтобы ликвидировать тупик. Например, ОС Unix, имеющая в ядре ряд массивов фиксированной размерности, потенциально страдает от тупиков, даже если они не обнаружены. Например, суммарное число процессов в системе определяется размерностью таблицы процессов. Если таблица заполнена, вероятность этого ничтожна, но такое может произойти, то для программы, которая делает вызов fork, резонно подождать некоторое время и попытаться осуществить этот вызов вновь. Следует ли отказываться от вызова fork, чтобы решить эту проблему? Максимальное число открытых файлов аналогичным образом ограничено размером таблицы индексных узлов. С ними может произойти аналогичная ситуация. Пространство выгрузки на диске - другой лимитируемый ресурс. Фактически любая таблица в ОС - конечный ресурс. Подход Unix состоит в том, чтобы игнорировать данную проблему в предположении, что большинство пользователей предпочтут случайный тупик нелепым правилам заставляющих их иметь один процесс, один открытый файл и т.п. ... Таким образом, мы сталкиваемся с нежелательным выбором между строгостью и удобством. Трудно найти общее, устраивающее всех решение В этой статье объясняется, как устранять взаимные блокировки, происходящие при работе продукта WebSphere Process Server (далее сокращенно Process Server), сконфигурированного для работы с базой данных DB2®. Рассматриваются наиболее распространенные причины взаимных блокировок и рекомендации по их предотвращению. После изучения материала данной статьи вы научитесь выполнять следующие операции:
Данная статья предназначена для следующих категорий специалистов, работающих с продуктом Process Server: разработчики приложений, тестировщики, администраторы и персонал службы поддержки. Предполагается, что читатели обладают технической квалификацией на уровне от среднего до высокого. Взаимные блокировкиВзаимная блокировка возникает в ситуациях, когда двум различным транзакциям (потокам) требуется заблокировать более одного общего ресурса. Типичный пример взаимной блокировки: транзакция T1 блокирует ресурс R1 и пытается заблокировать ресурс R2, а в это время транзакция T2 уже заблокировала ресурс R2 и пытается заблокировать ресурс R1. В результате обе транзакции T1 и T2 находятся в состоянии бесконечного ожидания. Если ресурсы R1 и R2 являются объектами базы данных, то процедура обнаружения взаимных блокировок DB2, которая исполняется через регулярные промежутки времени (задаваемые значением конфигурационного параметра базы данных DLCHKTIME), обнаружит эту ситуацию. Эта процедура принудительно заставит одну из транзакций, например, T2, снять все свои блокировки и выполнить откат назад. Это позволит продолжить исполнение транзакции T1, а транзакцию T2 повторить позднее, после завершения операции отката. Тайм-аутыТайм-ауты блокировки возникают в ситуациях, когда одна транзакция удерживает исключительную блокировку ресурса на протяжении слишком продолжительного времени, а другая транзакция ждет возможности для обновления этого ресурса. Этот интервал времени может быть сконфигурирован в DB2 посредством задания соответствующего значения конфигурационного параметра LOCKTIMEOUT. Если значение параметра LOCKTIMEOUT будет превышено, то ожидающая транзакция получит исключение «тайм-аут блокировки» и выполнит откат назад. |