Реферат: Новые возможности операционных систем - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Новые возможности операционных систем

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Архив Zip, 37 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

Новые возможности операционных систем Содержание Эффективное испол ьзование легковесных процессов в симметричных мультипроцессорах Контекст процесса Ядерные нити Пользовательские легковесные процессы Пользовательские нити Методология применения легковесных процессов Современные файловые системы Ограничения традицио нных файловых сис тем Распространенные файловые системы Файловые системы с журнализацией Эффективное ис пользование легковесных процессов в симметричных мультипроцессорах Поддерживаемые в современных операционных системах (в частнос ти , в ОС UNIX) понятия нити (thread), потока упр авления , или легковесного процесса на самом деле появились и получили реализацию около 30 лет тому назад . Наиболее известной опера ционной системой , ориентированной на поддержку множественных процессов , которые работают в общем ад р есном пространстве и с общими прочими ресурсами , была легендарная ОС Multics. Эта операционная система заслуживает длительного отдельного обсуждения , но , естестве нно не в данном курсе . Мы рассмотрим (в общих чертах ) особенности легковесных процес сов в сов р еменных вариантах опера ционной системы UNIX. По всей видимости , все и ли почти все содержимое этого раздела мож но легко отнести к любой операционной сис теме , поддерживающей легковесные процессы . Несмотр я на различия в терминологии , в различных реализациях л егковесных процессов выделяются три класса . Но прежде , чем пере йти к рассмотрению этих классов , обсудим о бщую природу процесса в ОС UNIX. Контекст процесса Каждому процессу соответствует контекст , в котором он выпо лняется . Этот контекст включает содержимо е пользовательского адресного пространства - польз овательский контекст (т.е . содержимое сегментов программного кода , данных , стека , разделяемых сегментов и сегментов файлов , отображаемых в виртуальную память ), содержимое аппаратных р егистров - регистровый контекст (таких , как регистр счетчика команд , регистр состояни я процессора , регистр указателя стека и ре гистров общего назначения ), а также структуры данных ядра (контекст системного уровня ), связанные с этим процессом . Контекст процесса системного уровня в ОС UNIX состоит из "статической " и "динамических " частей . У каждого процесса имеется одна статическая часть контекста системного уровня и переме нное число динамических частей . Статическая часть контекста процесса сист емного уровня включает следующее : A .Описатель процесса , т.е . элемент та блицы описателей существующих в системе проце ссов . Описатель процесса включает , в частности , следующую информацию : · состояние процесса ; · физический адрес в основной или внешней памяти u-области процес са ; · идентифик аторы п ользователя , от имени которого запущен процес с ; · идентификатор процесса ; · прочую информацию , св язанную с управлением процессом . B. U-область (u-area), инд ивидуальная для каждого процесса область прос транства ядра , обладающая тем свойством , что хотя u-область каждого процесса располагае тся в отдельном месте физической памяти , u- области всех процессов имеют один и тот же виртуальный адрес в адресном пространст ве ядра . Именно это означает , что какая бы программа ядра не выполнялась , она в сегда вып о лняется как ядерная час ть некоторого пользовательского процесса , и и менно того процесса , u-область которого являетс я "видимой " для ядра в данный момент вр емени . U-область процесса содержит : · указатель на описатель процесса ; · идентификаторы пользоват еля ; · счетчик времени , кото рое процесс реально выполнялся (т.е . занимал процессор ) в режиме пользователя и режиме ядра ; · параметры системного вызова ; · результаты системного вызова ; · таблица дескрипторов открытых файлов ; · предельные размеры а дресного пространства процесса ; · предельные размеры ф айла , в который процесс может писать ; · и т.д . Динамическая част ь контекста процесса - это один или нескол ько стеков , которые используются процессом пр и его выполнении в режиме ядра . Число ядерных стеков про цесса соответствует чис лу уровней прерывания , поддерживаемых конкретной аппаратурой. Ядерные нити Базовым классом являются ядерные нити . В мире UNIX это не новость . Когда в пользовательском процессе происходит системный вызов или прерывание , вы полняется яд ерная составляющая пользовательс кого процесса в своем собственном контексте , включающем набор ядерных стеков и регист ровое окружение . Естественно , все ядерные сост авляющие пользовательских процессов работают в общем адресном пространстве с общим наборо м р е сурсов ядра . Поэтому их вп олне можно назвать ядерными легковесными проц ессами . Наличие ядерных нитей , в частности , облегчает обработку прерываний в режиме ядра . Как и в случае прерывания обычного п ользовательского процесса , обработка прерывания я дерной ни т и производится в ее контексте , и после возврата из прерывания продолжается выполнение прерванной ядерной нит и . Кроме того , каждая ядерная нить , вообще говоря , обладает собственным приоритетом по отношению к праву выполняться на процесс оре (конечно , этот п р иоритет связа н с приоритетом соответствующего пользовательско го процесса ). Это позволяет использовать гибку ю политику планирования процессорных ресурсов для ядерных составляющих . Итак , ядерные нити должны существовать независимо от того , п оддерживаются ли легковесные процессы в режиме пользователя . Наверное , трудно найти сегодня какую-либо многопользовательскую операци онную систему , в ядре которой в каком-то виде не поддерживались бы нити . Пользовательские легковесные процессы Видимо , следующим по важности классом легковесных процес сов являются пользовательские LWP (LightWeight Processes). Механизмы э того рода позволяют пользователям организовать несколько потоков управления в одном адрес ном пространстве . Все LWP одного пользовательского процесса совместно используют все р есурсы процесса . При поступлении процессу сиг нала на этот сигнал реагируют все LWP в соответствии со своими собственными установками . С другой стороны , каждый LWP обладает своим собственным контекстом , включающим , как и в случае ядерных ни т ей , стек и регистровое окружение (в частности , содержимо е индивидуального счетчика команд ). Любому LWP по льзовательского процесса соответствует отдельная ядерная нить . Это означает , что каждый LWP мо жет отдельно планироваться (и поэтому LWP одного пользов а тельского процесса могут параллельно выполняться на разных процессорах симметричного мультипроцессорного компьютера ), и системные вызовы и прерывания LWP могут обр абатываться независимо . Основным преимуществом ис пользования LWP является возможность достиж е ния реального распараллеливания программы при ее выполнении на симметричном мультипр оцессоре (на недостатках мы остановимся ниже ). Пользовательские нити Наконец , к тре тьему классу легковесных процессов относятся пользовательские нити . Они называются польз овательскими , поскольку реализуются не яд ром ОС , а с помощью специальной библиотеки функций (поэтому , например , в ОС Mach их н азывают C-Threads). Это тоже очень старая идея , к использованию которой неоднократно прибегали все опытные программисты (здесь уж е даже не важно , в среде какой оп ерационной системы выполняется программа ). Суть идеи состоит в том , что вся программа пользователя строится в виде набора сопрог рамм (coroutine), которые выполняются под управлением общего монитора . Естественно , что в монит о ре поддерживаются контексты всех сопрограмм , но и монитор , и сопрограммы являются составляющими одного пользовательского процесса , которому соответствует одна ядерная нить . Конечно , с использованием пользовательских нитей невозможно достичь реального расп а раллеливания программы . Единственный реальный эффект , которого можно добиться , сост оит в возможности распараллеливания обменов п ри использовании асинхронного режима системных вызовов . Как считают некоторые специалисты ( к числу которых не относится автор э т ой части курса ), основное достоин ство использования пользовательских нитей состои т в лучшей структуризации программы . Методология приме нения легковесных процессов Мы проследили достоинства разных видов легковесных процессов и можем перейти к краткому анал изу их недостатков . Многие программисты (включая автора статьи ) испытали эти недостатки на себе . При программировании с явным исполь зованием техники легковесных процессов возникает потребность в явной синхронизации по отн ошению к общим ресурсам . В совреме н ных вариантах ОС UNIX имеется несколько р азновидностей средств синхронизации : блокировки , с емафоры , условные переменные . Но в любом с лучае , механизм синхронизации является явным , оторванным от ресурса , для доступа к котор ому производится синхронизация . Ес л и у легковесных процессов одного пользовательс кого процесса общих ресурсов немного , то т акую программу написать и отладить сравнитель но несложно . Но при наличии большого колич ества общих ресурсов отладка программы станов ится очень сложным делом (даже при и спользовании только пользовательских нитей ). Основной проблемой является недетерминирован ность поведения программы , поскольку время вы полнения каждого легковесного процесса , вообще говоря , различно при каждом запуске програм мы . При использовании явных при митивов для синхронизации набора легковесных процессов наиболее распространенной ошибочной ситуацией является возникновение синхронизационных тупиков . Если при отладке параллельной программы возник тупик , нужно исследовать ситуацию , уста новить причину ее в озникновения (как правило , эта причина состоит в несогласов анном выполнении синхронизационных примитивов в разных легковесных процессах ) и устранить причину тупика . Но по причине недетерминиро ванности поведения программы тупики могут воз никать при одном и з ста запуске программы , и никогда нельзя быть полность ю уверенным , что при некотором сочетании в ременных характеристик тупик все-таки не проя вится . Заметим , что это относится и к LWP, и к пользовательским нитям . Трудно также согласиться с тем , что использ ование явных средств распараллелива ния улучшает структурность программы . Человеку свойственно последовательное мышление . Для прог раммиста наиболее естественна модель фон Нейм ана . С другой стороны , было бы странно не использовать возможности мультипроцессо р ов для повышения скорости выполнения программ . В настоящее время явное использован ие пользовательских LWP является единственным досту пным решением . Конечно , появление в современных операцио нных системах механизма процессов , работающих на общей памяти , не является слишком прогрессивным явлением . Традиционный UNIX стимулировал простое и понятное программирование . Совреме нный UNIX провоцирует сложное , запутанное и опасн ое программирование . С другой стороны , системные программисты с успехом используют новые с редства . При наличии большого желания , времени и денег параллельную программу можно надежно отладить , что демонстрирует большинство комп аний , разрабатывающих программное обеспечение баз данных . При этом используются и LWP, поддерж иваемые операционной сист е мой , и п ользовательские нити . Как кажется (это мнение не только автора ), использование LWP безусловно оправдано , если сервер БД конфигурируется в расчете на работу на симметричном му льтипроцессоре . На сегодняшний день это единс твенная возможность реально р аспараллел ить работу сервера . Но совершенно неочевидно , что применение пользовательских нитей при разработке сервера в целях его структуриза ции (а это делается во многих серверах ), является лучшим решением . Известны другие методы структуризации , которые , п о ме ньшей мере , не менее удобны . Современные фа йловые системы Ограничения тради ционных файловых систем При работе с внешней памятью мы по-прежнему в основном имеем дело с магнитными дисками с по движными головками . Если несколько лет тому назад казалось , ч то это временное я вление , и что наступит такое время , когда электро-механические задержки доступа к внеш ней памяти скоро исчезнут , то теперь уже понятна устойчивость таких устройств , сопров ождаемая постоянным снижением их стоимости . В чем состоит проблема ? На практике наиболее распространена после довательная работа с файлами . Если требуется произвести последовательный просмотр файла , хранящегося на магнитном диске с подвижными головками , то основные задержки создают и менно электро-механическом действия , св язанные с перемещением магнитных головок . Известно , что в среднем время движения головок н а два порядка превышает время двух послед ующих актов - ожидания подкрутки диска до нужного блока (тоже долго , но не так ) и собственно выполнения обмена (это как раз д остаточно быстро , и чем дальше , тем быстрее по мере развития технологии магнитных носителей ; к сожалению заставить быстро двигаться пакеты магнитных головок не так легко ). Основной неприятностью традиционных файловых систем являлось хаотическое распределе ни е внешней памяти . Один блок внешней памяти файла мог отстоять на произвольное колич ество цилиндров , т.е . элементов передвижения го ловок . Коренной перелом произошел в так на зываемой "быстрой файловой системе ", разработанной Кирком МакКусиком в рамках про е кта BSD 4.3. МакКусик решил , что лучше голов кам магнитного диска двигаться не слишком сильно . Поэтому было введено понятие группы магнитных цилиндров , в пределах которых д олжен располагаться файл . Вместо произвольного передвижения магнитных головок в масш т абе всей поверхности диска для послед овательного чтения файла требуется ограниченное смещение головок в выделенной группе цил индров . Но это не решает всех проблем . Появились устройства с магнитными дисками , предъявляющие внешнему миру интерфейс с 24 магни тными головками в то время , когд а на самом деле (физически ) их было 15. И что же теперь оптимизируется ? Аппаратура и встроенное программное обеспечение контроллеро в магнитных дисков сами производят собственну ю оптимизацию , а файловая система считает , что в се уже оптимизировано . Еще хуже дела стали с появлением дисковых мас сивов , особенно начиная с пятого уровня ор ганизации . RAID обеспечивает надежное хранение данных с 90-процентной гарантией и разделенное хр анение блока данных на всех дисках , входящ их в ма с сив . Что же теперь оптимизируют операционная система по отношению к доступу к файлам ? Это одна из о сновных проблем современных файловых систем ; она не решена , и не ясно , будет ли решена в ближайшее время . Тем не менее , файловые системы развиваются , и мы д а лее приведем обзор наиболее инте ресных существующих файловых систем (из мира UNIX) и некоторые примеры перспективных файловых систем. Распространенные файловые системы Понятие файла является одним из наиболее важных для ОС UNIX. Все файлы , с которыми могут манипу лировать пользователи , располагаются в файловой системе , представляющей собой дерево , промежуто чные вершины которого соответствуют каталогам , и листья - файлам и пустым каталогам . Ре ально на каждом логическом диске (разделе физического дискового па к ета ) распола гается отдельная иерархия каталогов и файлов . Для получения общего дерева в динамике используется "монтирование " отдельных иерархий к фиксированной корневой файловой системе . Замечание : в мире ОС UNIX по историческим причинам термин "файловая система " являе тся перегруженным , обозначая одновременно иерархи ю каталогов и файлов и часть ядра , кот орая управляет каталогами и файлами . Видимо , было бы правильнее называть иерархию катал огов и файлов архивом файлов , а термин "файловая система " использов а ть толь ко во втором смысле . Однако , следуя традиц ии ОС UNIX, мы будем использовать этот термин в двух смыслах , различая значения по контексту . Каждый каталог и файл файловой систем ы имеет уникальное полное имя (в ОС UNIX э то имя принято называть full path name - имя , задаю щее полный путь , посколько оно действительно задает полный путь от корня файловой системы через цепочку каталогов к соответс твующему каталогу или файлу ; мы будем испо льзовать термин "полное имя ", поскольку для pathname отсутствует благозв у чный русский аналог ). Каталог , являющийся корнем файловой системы (корневой каталог ) в любой файловой системе имеет предопределенное имя "/" (слэш ). Полное имя файла , например , /bin/sh означает , что в корневом каталоге должно содержаться имя каталога bin, а в каталоге bin должно содержаться имя файла sh. Коротким или отно сительным именем файла (relative pathname) называется имя (в озможно , составное ), задающее путь к файлу начиная от текущего рабочего каталога (сущест вует команда и соответствующий системный вызов , позволяющие установить текущий раб очий каталог . В каждом каталоге содержатся два спец иальных имени , имя ".", именующее сам этот ка талог и имя "..", именующее "родительский " каталог данного каталога , т.е . каталог , непосредственно предшествующий данн ому в иерархии ка талогов . UNIX поддерживает многочисленные утилиты , позво ляющие работать с файловой системой и дос тупные как команды командного интерпретатора . Вот некоторые из них (наиболее употребительны е ): · cp имя 1 имя 2 - копиров ание файла имя 1 в фай л имя 2 · rm имя 1 - уничтожение файла имя 1 · mv имя 1 имя 2 - переименование файла имя 1 в файл имя 2 · mkdir имя - создание нового каталога имя · rmdir имя - уничтожение каталога имя · ls имя - выдача содержимого каталога им я · cat имя - выдача на экран содержимо го файла имя · chown имя режим - изменение режима доступ а к файлу Файловая система обычно размещается на дисках или других устройствах внешней памяти , имеющих блочную структуру . Кроме блоков , сохраняющих каталоги и файлы , во внешней памяти подде р живается еще несколько служебных областей . В мире UNIX существует несколько разных в идов файловых систем со своей структурой внешней памяти . Наиболее известны традиционная файловая система UNIX System V (s5) и файловая система с емейства UNIX BSD (ufs). Ф айловая система s5 состоит из четырех секций (рисунок 6.1(a)). В файловой сис теме ufs на логическом диске (разделе реального диска ) находится последовательность секций ф айловой системы . Кратко опишем суть и назначение каждо й области диска : · Boot-блок со держит программу раск рутки , которая служит для первоначального зап уска ОС UNIX. В файловых системах s5 реально исп ользуется boot-блок только корневой файловой сис темы . В дополнительных файловых системах эта область присутствует , но не используется . Рис . 6.1. · Суперблок - это наиболее ответственная область файловой системы , содержащая инфо рмацию , которая необходима для работы с фа йловой системой в целом . Суперблок содержит список свободных блоков и свободные i-узлы (information nodes - информационные узлы ). В файловых система х usf для повышения устойчивости поддерживается несколько ко п ий суперблока (как ви дно из рисунка 6.1(b), по одной копии на гр уппу цилиндров ). Каждая копия суперблока имеет размер 8196 байт , и только одна копия суп ерблока используется при монтировании файловой системы (см . ниже ). Однако , если при монти ровании устана в ливается , что первична я копия суперблока повреждена или не удов летворяет критериям целостности информации , испол ьзуется резервная копия . · Блок группы цилиндро в содержит число i-узлов , специфицированных в списке i-узлов для данной группы цилиндров , и числ о блоков данных , которые св язаны с этими i-узлами . Размер блока группы цилиндров зависит от размера файловой си стемы . Для повышения эффективности файловая с истема ufs старается выделять i-узлы и блоки данных в одной и той же группе цилинд ров . · Список i-у злов (ilist) содержит список i-узлов , соответствующих файла м данной файловой системы . Максимальное число файлов , которые могут быть созданы в файловой систем , определяется числом доступных i-узлов . В i-узле хранится информация , описываю щая файл : режимы до с тупа к фай лу , время создания и последней модификации , идентификатор пользователя и идентификатор гру ппы создателя файла , описание блочной структу ры файла и т.д . · Блоки данных - в э той части файловой системы хранятся реальные данные файлов . В случае файло вой системы ufs все блоки данных одного файла пы таются разместить в одной группе цилиндров . Размер блока данных определяется при форма тировании файловой системы командой mkfs и может быть установлен в 512, 1024, 2048, 4096 или 8192 байт . Файлы любой фа йло вой системы становятся доступными толь ко после "монтирования " этой файловой системы . Файлы "не смонтированной " файловой системы не являются видимыми операционной системой . Для монтирования файловой системы использ уется системный вызов mount. Монтирование файлов ой системы означает следующее . В имеющейся к моменту монтирования дереве каталогов и файлов должен иметься листовой узел - пус той каталог (в терминологии UNIX такой каталог , используемый для монтирования файловой системы , называется directory mount p oint - точка монтирования ). В любой файловой системе имеется корнев ой каталог . Во время выполнения системного вызова mount корневой каталог монтируемой файловой системы совмещается с каталогом - точкой монтирования , в результате чего образуется но вая иера р хия с полными именами каталогов и файлов . Смонтированная файловая система впоследствии может быть отсоединена от общей иерархии с использованием системного вызова umount. Для успешного выполнения этого системного вызова требуется , чтобы отсоединяемая файл овая системы к этому моменту не находилась в использовании (т.е . ни один файл из э той файловой системы не был открыт ). Корне вая файловая система всегда является смонтиро ванной , и к ней не применим системный вызов umount. Как мы отмечали выше , отдельная фа йловая система обычно располагается на логическом диске , т.е . на разделе физическог о диска . Для инициализации файловой системы не поддерживаются какие-либо специальные систем ные вызовы . Новая файловая система образуется на отформатированном диске с исполь з ованием утилиты (команды ) mkfs. Вновь созданная файловая система инициализируется в состояни е , соответствующее наличию всего лишь одного пустого корневого каталога . Команда mkfs выполня ет инициализацию путем прямой записи соответс твующих данных на диск . Я дро ОС UNIX поддерживает для работы с файлами несколько системных вызовов . Ср еди них наиболее важными являются open, creat, read, write, lseek и close. Важно отметить , что хотя внутри подсис темы управления файлами обычный файл представ ляется в виде набора блоков внешней памяти , для пользователей обеспечивается представ ление файла как линейной последовательности б айтов . Такое представление позволяет использовать абстракцию файла при работе в внешними устройствами , при организации межпроцессных вза имодейств и й и т.д . Файл в системных вызовах , обеспечивающих реальный доступ к данным , идентифицируется своим дескриптором (целым значением ). Дескриптор файла выдается системными вызовами open (открыть файл ) и creat (создать файл ). Основным параметр ом операций откры тия и создания файла является полное или относительное имя фа йла . Кроме того , при открытии файла указыв ается также режим открытия (только чтение , только запись , запись и чтение и т.д .) и характеристика , определяющая возможности доступа к файлу : open(pathname, oflag [,mode]) Одним из призн аков , могущих участвовать в параметре oflag, являет ся признак O_CREAT, наличие которого указывает на необходимость создания файла , если при выпо лнении системного вызова open файл с указанным именем не существует (параметр mode имеет смысл только при наличии этого признака ). Тем не менее по историческим причинам и для обеспечения совместимости с предыдущ ими версиями ОС UNIX отдельно поддерживается сис темный вызов creat, выполняющий практически те же функции . Откры тый файл может использоваться для чтения и записи последовательностей ба йтов . Для этого поддерживаются два системных вызова : read(fd, buffer, count) и write(fd, buffer, count) Здесь fd - дескриптор файла (полученный при ранее выполненном с истемном вызове open или creat), buffer - указатель симво льного массива и count - число байтов , которые д олжны быть прочитаны из файла или в н его записаны . Значение функции read или write - целое число , которое совпадает со значением count, есл и операция заканчивается ус п ешно , равно нулю при достижении конца файла и отрицательно при возникновении ошибок . В каждом открытом файле существует те кущая позиция . Сразу после открытия файл п озиционируется на первый байт . Другими словам и , если сразу после открытия файла выполня ется системный вызов read (или write), то будут прочитаны (или записаны ) первые count байт содер жимого файла (конечно , они будут успешно п рочитаны только в том случае , если файл реально содержит по крайней мере count байт ). После выполнения системного вызова r ead (или write) указатель чтения /записи файла будет установлен в позицию count+1 и т.д . Такой чисто последовательный стиль работы оказывается во многих случаях достаточным , но часто бывает необходимо читать или изменять файл с произвольной позиции (наприм ер , как без такой возможности хранить в файле прямо индексируемые массивы данн ых ?). Для явного позиционирования файла служит системный вызов lseek(fd, offset, origin) Как и раньше , здесь fd - дескриптор ранее открытого файла . Параметр offset задает значен ие относительного смещения указателя чтения /записи , а парамет р origin указывает , относительно какой позиции долж но применяться смещение . Возможны три значени я параметра origin. Значение 0 указывает , что значени е offset должно рассматриваться как смещение о тносительно начала файла . Значение 1 означает , что значение offset является смещением относительно текущей позиции файла . Наконец , значение 2 говорит о том , что задается с мещение относительно конца файла . Заметим , что типом данных параметра offset являетс я long int. Это значит , что , во-первых , могут з адаваться достаточно длинные смещения и , во-вт орых , смещения могут быть положительными и отрицательными . Например , после выполнения системного выз ова lseek(fd, 0, 0) указатель чтения /записи соответствующего ф айла будет установлен на начало (на первый байт ) файл а . Системный вызов lseek(fd, 0, 2) установит указате ль на конец файла . Наконец , выполнение сис темного вызова lseek(fd, 10, 1) приведет к уве личению текущего значения указателя на 10. Естественно , сист емный вызов успешно завершается только в том случае , когда заново сформированное значение указателя не выходит за пределы существующих размеров ф айла. Файловые системы с журнализацией Одним из наибо лее существенных недостатков традиционных файлов ых систем является трудность восстановления согласованного состояния файлов после сбоев , в результате которых теряется содержимое основной памяти . Это связано с тем , что для повышения эффективности работа с вне шней памятью производится через буфера основн ой памяти, в которых в момент с боя могут находиться как данные (содержимое блоков файла ), так и метаданные (например , содержимое i-узлов ). Обычным приемом восстановлен ия файловой системы после сбоя является п рименение утилиты fsck, которая , работая на уровне логичес к ого диска , обходит всю файловую систему и , по мере возможности , находит и исправляет ошибочные ситуации . Ес тественно , если используются большие диски , то эта работа занимает много времени , привод я к серьезным задержкам в использовании к омпьютера . Для устр а нения этого не достатка все чаще применяются файловые систем ы с журнализацией . Как и в случае журнализации изменений в системах управления базами данных , осно вным принципом журнализующих файловых систем является поддержание специального файла-журнала , в ко торый в последовательном и только последовательном режиме записывается информация обо всех изменениях файловой системы . Зап ись , как правило , производится порциями большо го объема , что обеспечивает высокий уровень полезного использования дисковой памяти и в ысокую эффективность . При восстановл ении после сбоя требуется использовать только "хвост " журнала , что позволяет производить восстановление быстро и надежно . Файловые системы с журнализацией разделяю тся на две категории : системы , производящие журнализацию всех изменений , и системы , журнализующие только изменения метаданных . Сре ди систем второй категории выделяются те , которые журнализуют только некоторую выделенную информацию (например , не помещают в журна л информацию о смене владельца файла ). Различаются подходы с журнализацией операций и журнализацией результатов операций . Если , например , журнализуется операция измене ния таблицы распределения памяти на диске , то выгоднее поместить в журнал информацию о самой операции (поскольку она изменяет только неско л ько бит информации на диске ). В случае же журнализации оп ерации записи блока данных выгоднее занести в журнал все содержимое блока до его изменения . Среди файловых систем с журнализацией выделяются такие , в которых журнал использу ется как вспомогательное средство , а стр уктура самой файловой системы не меняется (в частности , как и в традиционных файло вых системах , поддерживаются структуры i-узлов и суперблоков ). Другой класс журнализующих фай ловых систем составляют те , в которых журн ал является единственны м средством представления файлов на магнитном диске . Имеется два типа журналов : журнал , ори ентированный только на повторное выполнение о пераций (redo-only), и журнал , способный поддерживать к ак повторное выполнение операций , так и их обратное выполнение (u ndo-redo). В журнале "undo-redo" сохраняются как новые , так и старые значен ия данных . При использовании журнала типа "redo-only" операции восстановления упрощаются , но требует ся ограничивать порядок записи метаданных в журнал и на место их постоянного хра н ения . Журнал "undo-redo" больше по объему и требует применения более сложного меха низма журнализации , но использование этого ти па журнализации допускает более высокий урове нь параллельности . Хотя имеются файловые системы , производящ ие архивизацию наиболее старых порций ж урнала , наиболее распространенным подходом являет ся использование циклического файла-журнала конеч ного размера . Для поддержки такого журнала применятся специализированная процедура "сборки мусора ", выявляющая "устарелые " порции журнальной и нформации . В некоторых системах эта процедура запускается на фоне работающ ей системы , в других - только при проведени и профилактических работ . Как упоминалось выше , для лучшего испо льзования дисковой памяти и увеличения эффект ивности записи в журнал произ водятся порциями большого объема . В результате часто в одну физическую запись пакуются нескол ько логических записей об изменении файловой системы . Естественно , это снижает надежность файловой системы , поскольку в случае сбоя последний буфер с журнальной и н формацией будет утрачен . На практике п риходится делать выбор между эффективностью и надежностью . Наиболее известной файловой системой , осн ованной исключительно на журнализации и журна лизующей все изменения , является BSD-LFS (UNIX BSD 4.4 Log-Structured Fi le System). Среди файловых систем , поддерживающих журнал изацию только метаданных , можно выделить Cedar, Calaveras и Veritas.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Добрым словом и минетом от мужика можно добиться большего, чем одним добрым словом.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, реферат по программированию "Новые возможности операционных систем", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru