Зв'язні списки з таблицею розміщення файлів 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Зв'язні списки з таблицею розміщення файлів



Цей підхід (рис. 12.4) полягає в тому, що всі посилання, які формують списки кластерів файла, зберігаються в окремій ділянці файлової системи фіксованого розміру, формуючи таблицю розміщення файлів (File Allocation Table, FAT). Еле­мент такої таблиці відповідає кластеру на диску і може містити:

 

 

· номер наступного кластера, якщо цей кластер належить файлу і не є його ос­таннім кластером;

· індикатор кінця файла, якщо цей кластер є останнім кластером файла;

· індикатор, який показує, що цей кластер вільний.

Для організації файла достатньо помістити у відповідний йому елемент каталога номер першого кластера файла. За необхідності прочитати файл система знаходить за цим номером кластера відповідний елемент FAT, зчитує із нього ін­формацію про наступний кластер і т. д. Цей процес триває доти, поки не трапить­ся індикатор кінця файла.

Використання цього підходу дає змогу підвищити ефективність і надійність розміщення файлів зв'язними списками. Це досягається завдяки тому, що розмі­ри FAT дозволяють кешувати її в пам'яті. Через це доступ до диска під час відстеження посилань заміняють звертаннями до оперативної пам'яті. Зазначимо, що навіть якщо таке кешування не реалізоване, випадковий доступ до файла не призводитиме до читання всіх попередніх його кластерів - зчитані будуть тільки по­передні елементи FAT.

Крім того, спрощується захист від збоїв. Для цього, наприклад, можна зберігати на диску додаткову копію FAT, що автоматично синхронізуватиметься з основ­ною. У разі ушкодження однієї з копій інформація може бути відновлена з іншої.

І нарешті, службову інформацію більше не зберігають безпосередньо у класте­рах файла, вивільняючи в них місце для даних. Тепер обсяг корисних даних все­редині кластера майже завжди (за винятком, можливо, останнього кластера файла) дорівнюватиме степеню числа 2.

Однак, у разі такого способу розміщення файлів для розділів великого розмі­ру обсяг FAT може стати доволі великим і її кешування може потребувати знач­них витрат пам'яті. Скоротити розмір таблиці можна, збільшивши розмір класте­ра, але це, в свою чергу, призводить до збільшення внутрішньої фрагментації для малих файлів (менших за розмір кластера).

Також руйнування обох копій FAT (внаслідок апаратного збою або дії програми-зловмисника, наприклад, комп'ютерного вірусу) робить відновлення даних дуже складною задачею, яку не завжди можна розв'язати.

 

 

Лекція №3.

 

Тема: Індексоване розміщення файлів

 

План:

1. Індексоване розміщення файлів (Л1 ст.290-291).

2. Структура індексних дескрипторів,розріджені файли (Л1 ст.291-293).

3. Організація каталогів (Л1 ст. 293-294).

4. Облік вільних кластерів (Л1 ст.294).

1.

Базовою ідеєю ще одного підходу до розміщення файлів є перелік адрес всіх кла­стерів файла в його заголовку. Такий заголовок файла дістав назву індексного де­скриптора, або і-вузла (іnode), а сам підхід - індексованого розміщення файлів.

За індексованого розміщення із кожним файлом пов'язують його індексний дескриптор. Він містить масив із адресами (або номерами) усіх кластерів цього файла, при цьому n-й елемент масиву відповідає n-му кластеру. Індексні дескрип­тори зберігають окремо від даних файла, для цього звичайно виділяють на почат­ку розділу спеціальну ділянку індексних дескрипторів. В елементі каталогу роз­міщують номер індексного дескриптора відповідного файла (рис. 12.5).

 

 

 

Під час створення файла на диску розміщують його індексний дескриптор, у якому всі покажчики на кластери спочатку є порожніми. Під час першого запи­сування в n-й кластер файла менеджер вільного простору виділяє вільний кла­стер і його номер або адресу заносять у відповідний елемент масиву індексного дескриптора.

Цей підхід стійкий до зовнішньої фрагментації й ефективно підтримує як пос­лідовний, так і випадковий доступ (інформація про всі кластери зберігається компактно і може бути зчитана за одну операцію). Для підвищення ефективності індексний дескриптор повністю завантажують у пам'ять, коли процес починає працювати з файлом, і залишають у пам'яті доти, поки ця робота триває.

 

 

2.

 

Основною проблемою є підбір розміру і задания оптимальної структури індекс­ного дескриптора, оскільки:

· з одного боку, зменшення розміру дескриптора може значно зекономити диско­вий простір і пам'ять (дескрипторів потрібно створювати значну кількість - по одному на кожний файл, разом вони можуть займати досить багато місця на диску; крім того, для кожного відкритого файла дескриптор буде розташо­вано в оперативній пам'яті).

· з іншого боку, дескриптора надто малого розміру може не вистачити для роз­міщення інформації про всі кластери великого файла.

Одне з компромісних розв'язань цієї задачі, яке застосовується вже багато ро­ків у UNIX-системах, зображене на рис. 12.6. Під час його опису замість терміна «кластер» вживатимемо його синонім «дисковий блок».

 

 

У цьому разі індексний дескриптор містить елементи різного призначення.

· Частина елементів (зазвичай перші 12) безпосередньо вказує на дискові бло­ки, які називають прямими (direct blocks). Отже, якщо файл може вміститися у 12 дискових блоках (за розміру блоку 4 Кбайт максимальний розмір такого файла становитиме 4096 х 12 = 49 152 байти), усі ці блоки будуть прямо адре­совані його індексним дескриптором і жодних додаткових структур даних не буде потрібно.

· Якщо файлу необхідно для розміщення даних більше, ніж 12 дискових блоків, використовують непряму адресацію першого рівня. У цьому разі 13-й елемент індексного дескриптора вказує не на блок із даними, а на спеціальний непря­мий блок першого рівня (single indirect block). Він містить масив адрес на­ступних блоків файла (за розміру блоку 4 Кбайт, а адреси - 4 байти в ньому міститимуться адреси 1024 блоків, при цьому максимальний розмір файла бу­де 4096 х (12 + 1024) = 4 234 456 байт).

· Якщо файлу потрібно для розміщення більше ніж 1024 + 12 = 1036 дискових блоків, використовують непряму адресацію другого рівня. 14-й елемент ін­дексного дескриптора в цьому разі вказуватиме на непрямий блок другого рівня (double indirect block). Такий блок містить масив з 1024 адрес непрямих блоків першого рівня, кожен із них, як зазначалося, містить масив адрес дис­кових блоків файла. Тому за допомогою такого блоку можна адресувати 10242 додаткових блоків.

· Нарешті, якщо файлу потрібно більше ніж 1036 + 10242 дискових блоків, ви­користовують непряму адресацію третього рівня. Останній 15-й елемент ін­дексного дескриптора вказуватиме на непрямий блок третього рівня (triple in­direct block), що містить масив з 1024 адрес непрямих блоків другого рівня, даючи змогу адресувати додатково 10243 дискових блоків.

Розмір блоку може відрізнятися від 4 Кбайт. Чим більший блок, тим більшим є розмір, що може бути досягнутий файлом, поки не виникне необхідності у не­прямій адресації вищого рівня. З іншого боку, більший розмір блоку спричиняє більшу внутрішню фрагментацію.

Можна розподіляти дисковий простір не блоками (кластерами), а їхніми група­ми (неперервними ділянками із кількох дискових блоків). Такі групи ще назива­ють екстентами (extents). Кожен екстент характеризується довжиною (у блоках) і номером початкового дискового блоку. Коли виникає необхідність виділити кілька неперервно розташованих блоків одночасно, замість цього виділяють ли­ше один екстент потрібної довжини. У результаті обсяг службової інформації, яку потрібно зберігати, може бути скорочений.

Характер перетворення адреси в номер кластера робить цей підхід аналогом сторінкової організації пам'яті, причому індексний дескриптор відповідає табли­ці сторінок.

Розріджені файли

Багато операційних систем не зберігають покажчики на дискові блоки файлів у їхніх індексних дескрипторах, поки до них не було доступу для записування. Фрагменти, до яких цього доступу не було з моменту створення файла, назива­ють «дірами» (holes), дисковий простір під них не виділяють, але під час розра­хунку довжини файла їх враховують. У разі читання вмісту «діри» повертають блоки, заповнені нулями, звертання до диска не відбувається.

На практиці «діри» найчастіше виникають, коли покажчик поточної позиції файла переміщують далеко за його кінець, після чого виконують операцію запи­сування. У результаті розмір файла збільшується без додаткового виділення дис­кового простору. Подібні файли називають розрідженими файлами (sparse files). Вони реально займають на диску місця набагато менше, ніж їхня довжина, фак­тично довжина розрідженого файла може перевищувати розмір розділу, на якому він перебуває.

 

3.

 

Каталоги звичайно організують як спеціальні файли, що містять набір елементів каталогу (directory entries), кожен з яких містить запис про один файл.

Елементи каталогу.

Елемент каталогу обов'язково містить ім'я файла та інформацію, що дає змогу за іменем файла знайти на диску адреси його кластерів. Структуру такої інформації визначають підходи до розміщення файлів: для неперервного розміщення в еле­менті каталогу зберігатиметься адреса початкового кластера і довжина файла, для розміщення зв'язними списками — тільки адреса або номер початкового кла­стера, для індексованого розміщення достатньо зберігати номер індексного деск­риптора файла.

Крім обов'язкових даних, елемент каталогу може зберігати додаткову інфор­мацію, характер якої залежить від реалізації. Це може бути, наприклад, набір ат­рибутів файла (так найчастіше роблять при неперервному розміщенні або розмі­щенні зв'язаними списками). З іншого боку, за індексованого розміщення всі атрибути файла та іншу службову інформацію зберігають в індексному дескрип­торі, а в елемент каталогу додаткову інформацію не заносять (там є тільки ім'я файла і номер дескриптора).

Організація списку елементів каталогу.

Реалізація каталогу включає також організацію списку його елементів. Найчасті­ше елементи об'єднують у лінійний список, але якщо в каталогах буде багато елементів, для підвищення ефективності пошуку файла можна вико­ристати складніші структури даних, такі як бінарне дерево пошуку або хеш-таб­лиця. Для прискорення пошуку можна також кешувати елементи каталогу(завантажувати їх у пам'ять), при цьому під час кожного пошуку файла спочатку перевіряється його наявність у ке­ші, у разі влучення пошук буде зроблено дуже швидко.

 

Організація підтримки довгих імен файлів

Розглянемо, яким чином у каталозі зберігають довгі імена файлів. Є ряд підходів до вирішення цієї проблеми.

· Найпростіше зарезервувати простір у кожному елементі каталогу для макси­мально допустимої кількості символів у імені. Такий підхід можна використа­ти, якщо максимальна кількість символів невелика, у протилежному випадку місце на диску витрачатиметься даремно, оскільки більша частина імен не зай­матиме весь зарезервований простір.

· Можна зберігати довгі імена в елементах каталогу повністю, у цьому випадку довжина такого елемента буде залежати від розміру файла і не буде фіксованою. Для цього перед кожним елементом ката­логу вказують його довжину, а кінець імені файла позначають спеціальним (зазвичай нульовим) символом. Недоліки цього підходу пов'язані з тим, що через різну довжину елементів виникає зовнішня фрагментація і каталог надто великого розміру може зайняти кілька сторінок у пам'яті, тому під час пере­гляду такого каталогу є ризик виникнення сторінкових переривань.

· Нарешті, можна зробити всі елементи каталогу однієї довжини, при цьому ко­жен із них міститиме покажчик на довге ім'я. Усі довгі імена зберігатимуться окремо (наприклад, наприкінці каталогу). Це вирішує проблему зовнішньої фрагментації для елементів каталогу, але ускладнює керування ділянкою для зберігання довгих імен.

4.

Окрім урахування кластерів, виділених під файли, файлові системи повинні вести облік вільних кластерів. Це необхідно для того щоб система могла ефективно виділяти дисковий простір під нові файли. Найчастіше використовують два способи керування вільним дисковим простором:

· Бітовий масив - бітова карта кластерів, у якій кожен біт відповідає одному кластеру на диску. Якщо відповідний кластер вільний, біт дорівнює 1, якщо зайнятий-0. Головна перевага цього підходу в можливості його апаратної реалізації за рахунок простого алгоритму (пошук першого ненульового біта), що дає змогу досягти максимальної швидкості.

· Зв’язний список вільних кластерів – використовують тоді, коли зв’язний список застосовується для розміщення файлів. До цього списку заносяться адреси вільних кластерів на диску. Елементами списку є кластери з адресами(номерами) вільних кластерів.

Для керування вільним дисковим простором одним із цих способів, достатньо зберігати в памяті один елемент списку вільних кластері, або один елемент із бітовою картою. Коли вільні бдоки в ньому закінчаться, зчитують наступний елемент. При видаленні файла номери його кластерів додають у поточний елемент списку, або в поточну бітову карту. Коли місця там для запису не залишається, то поточний елемент(карту) записують на диск, а в памяті створюють новий елемент або карту, куди заносять номери кластерів, яким не вистачило місця.

 

Лекція №4.

 

Тема: Надійність файлових ситем.

 

План:

1. Оптимізація продуктивності під час розробки файлових систем (Л1 ст.295-296).

2. Надійність файлових систем (Л1 ст. 303-304).

3. Резервне копіювання (Л1 ст. 304-305).

4. Фізичне та логічне архівування. (Л1 ст. 305).

5. Системне відновлення у Windows XP (Л1 ст. 305).

6. Журнальні файлові системи (Л1 ст. 309-310).

 

1.

Розглянемо, яким чином можна оптимізувати продуктивність файлової системи зміною структур даних і алгоритмів, які в ній застосовують. У викладі використо­вуватимемо класичний приклад оптимізації традиційної файлової системи вихід­ної версії UNIX під час розроблення системи Fast File System (FFS) для BSD UNIX (у наш час ця файлова система також відома як ufs).

Традиційна файлова система UNIX складається із суперблока (що містить номери блоків файлової системи, поточну кількість файлів, покажчик на список вільних блоків), ділянки індексних дескрипторів і блоків даних (рис. 12.7). Розмір блока фіксований і становить 512 байт. Вільні блоки об'єднані у список.

Супер-блок Індексні дескриптори Блоки даних (по 512 байт)

 

 

Рис. 12.7. Традиційна файлова система UNIX

 

Така система є прикладом простого і витонченого вирішення, яке виявилось неприйнятним із погляду продуктивності. На практиці ця файлова система могла досягти на пересиланні даних пропускної здатності, що становить усього 2 % можливостей диска. Назвемо деякі причини такої низької продуктивності.

· Розмір дискового блоку виявився недостатнім, внаслідок чого для розміщен­ня даних файла була потрібна велика кількість блоків; індексні дескриптори навіть для невеликих файлів потребували кількох рівнів непрямої адресації, перехід між якими сповільнював доступ; пересилання даних одним блоком призводила до зниження пропускної здатності.

· Пов'язані об'єкти часто виявлялися віддаленими один від одного і не могли бути зчитані разом, зокрема, індексні дескриптори були розташовані далеко від блоків даних і для каталогу не перебували разом; послідовні блоки для файла також не містилися разом (це траплялося тому, що протягом експлуата­ції системи через вилучення файлів список вільних блоків ставав «розкиданим» по диску, внаслідок чого файли під час створення отримували блоки, віддале­ні один від одного).

До розв'язання цих проблем під час розробки файлової системи FFS були за­пропоновані декілька підходів.

Насамперед, у цій системі було збільшено розмір дискового блока (у FFS використовували два розміри блока: 4 і 8 Кбайт). Для того щоб уникнути внутрішньої фрагментації (яка завжди зростає зі збільшенням розміру блока), було запропоновано в разі необхідності розбивати невикористані блоки на части­ни меншого розміру - фрагменти, які можна використати для розміщення неве­ликих файлів. Мінімальний розмір фрагмента дорівнює розміру сектора диска, тому було використано фрагменти на 1 Кбайт.

Крім того, велику увагу було приділено групуванню взаємозалежних даних. З огляду на те, що найбільші втрати часу трапляються під час переміщення го­ловки, було запропоновано розміщувати такі дані в рамках групи циліндрів, яка об'єднує один або кілька суміжних циліндрів. Під час доступу до даних однієї та­кої групи головку переміщувати було не потрібно, або її переміщення виявлялося мінімальним. Кожна така група за своєю структурою повторювала файлову систе­му: у ній був суперблок, ділянка індексних дескрипторів і ділянка дискових блоків, виділених для файлів. Тому індексний дескриптор кожного файла розміщувався в тому самому циліндрі, що і його дані, в одній групі циліндрів розміщувалися та­кож всі індексні дескриптори одного каталогу. Послідовні блоки файла прагнули розміщувати в суміжних секторах.

Нарешті, ще одна важлива зміна була зроблена у форматі зберігання інформа­ції про вільні блоки - список вільних блоків було замінено бітовою картою, яка могла бути повністю завантажена у пам'ять. Пошук суміжних блоків у такій карті міг бути реалізований ефективніше. Для ще більшої ефективності цього процесу в системі постійно підтримували деякий вільний простір на диску (коли є вільні дискові блоки, ймовірність знайти суміжні блоки зростає).

Внаслідок реалізації цих і деяких інших рішень пропускна здатність файлової системи зросла в 10-20 разів (до 40 % можливостей диска). На підставі цього прикладу можна зробити такі висновки:

· розмір блоку впливає на продуктивність файлової системи, при цьому потріб­но враховувати можливість внутрішньої фрагментації;

· програмні зусилля, витрачені на скорочення часу пошуку і ротаційної затрим­ки, окупаються (насамперед вони мають спрямовуватися на забезпечення су­міжного розміщення взаємозалежної інформації);

· використання бітової карти вільних блоків теж спричиняє підвищення про­дуктивності.

Ідеї, що лежать в основі FFS, вплинули на особливості проектування файло­вої системи ext2fs - основної файлової системи Linux.

2.

Надійність файлових систем визначається можливістю відновлення їхніх даних після краху комп’ютерної системи. При цьому виникають наступні проблеми.

· У разі використання дискового кеша дані, що перебувають у ньому, після від­ключення живлення зникнуть. Якщо до цього моменту вони не були записані на диск, зміни в них будуть втрачені. Більш того, коли такі зміни були частко­во записані на диск, файлова система може опинитися у суперечливому стані.

· Файлова система може опинитися у суперечливому стані внаслідок частково­го виконання операцій із файлами. Так, якщо операція вилучення файла ви­далить відповідний запис із каталогу та індексний дескриптор, але через збій не встигне перемістити відповідні дискові блоки у список вільних блоків, вони виявляться «втраченими» для файлової системи, оскільки розмістити в них нові дані система не зможе.

Щоб забезпечити відновлення після системного збою, можна

· заздалегідь створити резервну копію всіх (або найважливіших) даних файло­вої системи, аби відновити їх з цієї копії;

· під час першого завантаження після збою дослідити файлову систему і випра­вити суперечності, викликані цим збоєм (при цьому файлова система має прагнути робити зміни так, щоб обсяг такого дослідження був мінімальним);

· зберегти інформацію про останні виконані операції і під час першого заванта­ження після збою повторити ці операції.

 

3.

Найвідомішим способом підвищення надійності системи є резервне копіювання даних (data backup). Резервним копіюванням або архівуванням називають процес створення на зовнішньому носії копії всієї файлової системи або її частини з ме­тою відновлення даних у разі аварії або помилки користувача. Аваріями є вихід жорсткого диска з ладу, фізичне ушкодження комп'ютера, вірусна атака тощо, по­милки користувача звичайно зводяться до вилучення важливих файлів. Резервні копії зазвичай створюють на дешевих носіях великого обсягу, найчастіше такими носіями є накопичувачі на магнітній стрічці або компакт-диски.

Одним із головних завдань резервного копіювання є визначення підмножини даних файлової системи, які необхідно архівувати.

· Звичайно створюють резервні копії не всієї системи, а тільки певної підмно­жини її каталогів. Наприклад, каталоги із тимчасовими файлами архівувати не потрібно. Часто не архівують і системні каталоги ОС, якщо їх можна відно­вити із дистрибутивного диска.

· Крім того, у разі регулярного створення резервних копій є сенс організувати інкрементне архівування (increment backup), коли зберігаються тільки ті дані, які змінились із часу створення останньої копії. Є різні підходи до організації інкрементних архівів. Можна робити повну резервну копію через більший проміжок часу (наприклад, через тиждень), а інкрементні копії - додатково із меншим інтервалом (наприклад, через добу); можна зробити повну копію один раз, а далі обмежуватися тільки інкрементними копіями. Основною пробле­мою тут є ускладнення процедури відновлення даних.

У момент створення резервної копії важливим є забезпечення несуперечливості файлової системи. В ідеалі резервну копію треба створювати, коли дані фай­лової системи не змінюються (з нею не працюють інші процеси). На практиці цього домогтися складно, тому використовують спеціальні засоби, які «фіксують» стан системи на деякий момент часу.

4.

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

Логічне архівування працює на рівні логічного відображення файлової систе­ми (файлів і каталогів). За його допомогою можна створити копію заданого ката­логу або інкрементну копію (при цьому відслідковують час модифікації файлів), на основі такого архіву можна відновити каталог або конкретний файл. Зазначи­мо, що для реалізації коректного відновлення окремих файлів у разі інкрементного архівування необхідно архівувати весь ланцюжок каталогів, що становлять шлях до зміненого файла, навіть якщо жоден із цих каталогів сам не модифіку­вався із моменту останнього архівування. Стандартну утиліту створення логіч­них резервних копій в UNIX-системах називають tar.

5.

Розглянемо приклад організації резервного копіювання на рівні ОС. Служба сис­темного відновлення (System Restore) Windows ХР дає змогу повертати систему в точку відновлення (restore point) - заздалегідь відомий стан, у якому вона пере­бувала в минулому. За замовчуванням точку відновлення створюють кожні 24 го­дини роботи системи, крім того, можна задавати такі точки явно (наприклад, під час встановлення програмного забезпечення).

Коли служба відновлення створює точку відновлення, формують каталог точки відновлення, куди записують поточні копії системних файлів, після чого спеціаль­ний драйвер системного відновлення починає відслідковувати зміни у файловій системі. Вилучені та змінені файли зберігають у каталозі точки відновлення, ін­формацію, що описує зміни (назви операцій, імена файлів і каталогів), заносять до журналу відновлення для цієї точки.

Під час виконання операції відновлення (Restore) системні файли копіюють із каталогу точки відновлення у системний каталог Windows, після чого відновлю­ють змінені файли користувача на підставі інформації із журналу відновлення.

6.

Великий обсяг дисків робить виконання програми перевірки і відновлення під час завантаження після збою досить тривалим процесом (для диска розміром у десятки Гбайтів така перевірка може тривати кілька годин). У деяких ситуаціях (наприклад, на серверах баз даних з оперативною інформацією) подібні затримки із відновленням роботоздатності системи після кожного збою можуть бути недо­пустимими. Необхідно організувати збереження інформації таким чином, щоб відновлення після збою не вимагало перевірки всіх структур даних на диску. Спроби розв'язати цю проблему привели до виникнення журнальних файлових систем (logging file systems).

Основна мета журнальної файлової системи - надати можливість після збою, замість глобальної перевірки всього розділу, робити відновлення на підставі ін­формації журналу (log) -спеціальної ділянки на диску, що зберігає опис остан­ніх змін. Використання журналу засноване на важливому спостереженні: під час відновлення після збою потрібно виправляти тільки інформацію, яка перебувала у процесі зміни у момент цього збою. Це та інформація, що не встигла повністю зберегтися на диску (зазвичай вона займає тільки малу його частину).

Основна ідея таких файлових систем - виконання будь-якої операції зміни даних на диску у два етапи.

1. Спочатку інформацію зберігають у журналі (у ньому створюють новий запис). Таку операцію називають випереджувальним записуванням (write-ahead) або веденням журналу (journaling).

Коли ця операція повністю завершена (було підтверджено зміну журналу), ін­формацію записують у файлову систему (можливо, не відразу). Після того, як зміну журналу було підтверджено, усі записи в журналі, створені на етапі 1, стають непотрібними і можуть бути вилучені. Зауважимо, що синхронізація журналу і реальних даних на диску може відбуватися і явно; виконання такої операції називають точкою перевірки (checkpoint). Дані із журналу після цієї перевірки теж можуть бути вилучені.

Читання даних завжди здійснюють із файлової системи, журнал у цій операції не бере участі ніколи.

Після того, як інформація про зміни потрапила в журнал, самі ці зміни мо­жуть бути записані у файлову систему не відразу. Часто об'єднують кілька опера­цій зміни даних у файловій системі, якщо вони належать до одного кластера, для того щоб виконати їх усі разом. У результаті кількість операцій звертання до дис­ка істотно знижується. Ще однією важливою обставиною підвищення продуктив­ності, є той факт, що операції записування в журнал виконують послідовно і без пропусків. Найкращої продуктивності можна домогтися, помістивши журнал на окремий диск.

Розмір журналу має бути достатній для того, щоб у ньому помістилися ті змі­ни, які на момент збою можуть перебувати у пам'яті.

Є різні підходи до того, яка інформація має зберігатися в журналі.

· Тільки описи змін у метаданих (до метаданих належить вся службова інфор­мація: індексні дескриптори, каталоги, імена тощо). Такий журнал забезпечує несуперечливість файлової системи після відновлення, але не гарантує від­новлення даних у файлах. З погляду продуктивності це найшвидший спосіб.

· Змінені кластери повністю. Такий підхід не вирізняється високою продуктив­ністю, натомість з'являється можливість відновити дані повністю. Файлові системи звичайно дають змогу вибрати варіант збереження інформа­ції в журналі (це може бути зроблено під час монтування системи). На практиці вибір підходу залежить від конкретної ситуації.

Програма відновлення файлів має розрізняти дві ситуації.

· Збій відбувся до підтвердження зміни журналу. У цьому разі здійснюють відкат (rollback): цю зміну ігнорують, і файлова система залишається в несуперечливому стані, у якому вона була до операції. Зазначимо, що такі атомарні опе­рації мають багато спільного із транзакціями — атомарними операціями у базі даних (відомо, що сервери баз даних для підтримки транзакцій також реалізу­ють роботу із журналом).

· Збій відбувся після підтвердження зміни журналу. За цієї ситуації потрібно відновити дані на підставі інформації журналу (такий процес ще називають відкатом уперед — rolling forward).

Журнал транзакцій у базі даних дає змогу підтверджувати і скасовувати ви­значений користувачем набір операцій зміни даних, що і є транзакцією. На відмі­ну від цього, підтвердження і відкат на підставі інформації журналу файлової системи можуть зачіпати тільки результати виконання окремих системних ви­кликів. Припустимо, що відбувається копіювання великого файла частинами, при цьому алгоритм копіювання в циклі звертається до системного виклику write() для копіювання кожної частини. Коли під час такого копіювання відбудеться збій між окремими викликами write(), то за будь-яких стратегій реалізації журналу файл залишиться скопійованим неповністю - не можна підтверджувати або ска­совувати кілька викликів як єдине ціле.

Сучасні операційні системи все більше переходять до використання журнальних файлових систем; наприклад, для Linux є декілька їх реалізацій (ext3fs, ReiserFS, XFS). Файлова система NTFS також підтримує ведення журналу.

 

Розділ 7. Керування пристроями вводу-виведення.

(аудиторних-8/6г., самостійних- 10/6г.)

 

Лекція №1.

 

Тема: Основні функції підсистеми вводу-виведення.

 

План:

1. Завдання підсистеми введення-виведення (Л1 ст. 358).

2. Забезпечення ефективності доступу до пристроїв (Л1 ст. 359).

3. Забезпечення спільного використання зовнішніх пристроїв (Л1 ст. 359).

4. Універсальність інтерфейсу прикладного програмування (Л1 ст. 359-360).

5. Універсальність інтерфейсу драйверів пристроїв (Л1 ст. 360-361).

6. Організація підсистеми введення –виведення (Л1 ст. 361-362).

 

 

1.

Основним завданням підсистеми введення-виведення є реалізація доступу до зов­нішніх пристроїв із прикладних програм, яка повинна забезпечити:

· ефективність (можливість використання ОС всіх засобів оптимізації, які на­дає апаратне забезпечення), спільне використання і захист зовнішніх при­строїв за умов багатозадачності;

· універсальність для прикладних програм (ОС має приховувати від приклад­них програм відмінності в інтерфейсі апаратного забезпечення, надаючи стан­дартний інтерфейс доступу до різних пристроїв), при цьому потрібно завжди залишати можливість прямого доступу до пристрою, оминаючи стандартний інтерфейс;

· універсальність для розробників системного програмного забезпечення (драй­верів пристроїв), щоб під час розробки драйвера для нового пристрою можна було скористатися наявними напрацюваннями і легко забезпечити інтеграцію цього драйвера у підсистему введення-виведення.

 

 

2.

 

Забезпечення ефективності вимагає розв'язання кількох важливих задач.

· Передусім - це коректна взаємодія процесора із контролерами пристроїв. Ві­домо, що кожен зовнішній пристрій має контролер, який забезпечує керуван­ня пристроєм на найнижчому рівні і є фактично спеціалізованим процесором. Після отримання команди від ОС контролер забезпечує її виконання, при цьому пристрій якийсь час не взаємодіє із процесором комп'ютера, тому той може виконувати інші задачі. Виконавши команду, контролер повідомляє сис­темі про завершення операції введення-виведення, генеруючи відповідну по­дію. Операційній системі в цьому разі потрібно спланувати процесорний час таким чином, щоб драйвери пристроїв могли ефективно реагувати на події контролера та було забезпечене виконання коду процесів користувача.

· Керування пам'яттю під час введення-виведення. Оперативна пам'ять є швид­шим ресурсом, ніж зовнішні пристрої, тому ОС може підвищувати ефектив­ність доступу до пристроїв проміжним зберіганням даних у пам'яті (із вико­ристанням таких технологій, як кешування і буферизація).

 

 

3.

Під час спільного використання зовнішніх пристроїв мають виконуватися певні умови.

· ОС повинна мати можливість забезпечувати одночасний доступ кількох проце­сів до зовнішнього пристрою і розв'язувати можливі конфлікти (тобто необ­хідна підтримка синхронізації доступу до пристроїв). Деякі пристрої (наприклад, модем або сканер) можна використати тільки одним процесом у конкретний момент часу, тоді як жорсткий диск завжди використовують спільно;

· Слід забезпечити захист пристроїв від несанкціонованого доступу. Такий за­хист можна організувати або для пристрою як цілого (наприклад, можна від­крити модем для доступу тільки певній групі користувачів), або для деякої підмножини даних пристрою (наприклад, різні файли на жорсткому диску можуть мати різні права доступу).

· У разі спільного використання пристрою треба розподілити операції введен­ня-виведення різних процесів, для того щоб уникнути «накладок» даних одних процесів на дані інших (наприклад, під час спільного використання принтера важливо відрізняти одні задачі від інших і не переходити до друкування ре­зультатів наступної задачі до того, як завершилося виведення попередньої).

4.

Оскільки пристрої введення-виведення доволі різноманітні, дуже важливо уніфі­кувати доступ до них із прикладних програм. Для реалізації цієї ідеї підсистема введення-виведення має використовувати набір базових абстракцій, під час засто­сування яких можна надати доступ до різних зовнішніх пристроїв узагальненим способом. Для більшості сучасних ОС такою абстракцією є абстракція файла, що відображається як набір байтів, з яким можна працювати за допомогою спеціаль­них операцій файлового введення-виведення. До таких операцій належать, на­приклад, системні виклики відкриття файла ореn (), файлового читання read () і записування write (). Файл, що відповідає пристрою (його називають файлом пристрою), не відповідає набору даних на диску, а є засобом організації універсального доступу різних компонентів ОС і прикладних програм до деякого пристрою введення-виведення.

Зазначимо, що не всі пристрої добре «вписуються» у модель файлового доступу (до подібних пристроїв належить, наприклад, системний таймер). У цьому разі, з одного боку, ОС може надавати унікальний, нестандартний інтерфейс до таких пристроїв, з іншого -стандартного набору файлових операцій може бути недо­статньо для використання всіх можливостей пристрою. Для вирішення цієї про­блеми можна запропонувати два підходи.

1. Розширити допустимий набір операцій, створивши інтерфейс, що відображає особливості конкретного пристрою. Його будують на основі стандартного фай­лового інтерфейсу, створюючи операції, характерні для конкретного пристрою. Ці операції, в свою чергу, використовують стандартні виклики, подібні до read () і write ().

2. Надати прикладним програмам можливість взаємодіяти із драйвером при­строю безпосередньо. Для цього звичайно пропонують універсальний систем­ний виклик (в UNIX його називають ioctl), у Windows ХР - DeviceIoControl (), параметри якого задають необхідний драйвер, команду, яку потрібно виконати, і дані для неї.

 

 

5.

Як відомо, драйвер пристрою - це програмний модуль, що керує взає­модією ОС із конкретним зовнішнім пристроєм.

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



Поделиться:


Последнее изменение этой страницы: 2017-02-05; просмотров: 476; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 44.192.247.185 (0.125 с.)