Срс 6: Нескінченне відкладання Нескінченне відкладання

Процеси, чекаючі ресурсів, встають в черзі до цих ресурсів. Така черга може обслуговуватися будь-якою невитісняючою стратегією планування. Моментом, коли менеджер ресурсу ухвалює рішення про обслуговування, є звільнення ресурсу.

Єдиною дисципліною, яка гарантує, що всі процеси в черзі будуть врешті-решт обслужені, є FCFS. Інші методи базуються на пріоритетах - зовнішніх або обчислюваних на підставі розміру запиту і/або безпеки ситуації. Черга може бути впорядкована за збільшенням розміру запиту, і при звільненні ресурсів останні можуть віддаватися по запиту "самого відповідного" розміру. Черга може бути впорядкована в порядку зростання небезпеки виділення ресурсів, і ресурс, що звільнився, може віддаватися тому процесу, запит якого найбезпечніший. При впорядкуванні черги, процес, що видав найбільший або найнебезпечніший запит, може надовго в ній застрягти, тобто, потрапити в ситуацію нескінченного відкладання. З іншого боку, застосування FCFS в чистому вигляді може привести до зниження рівня мультипрограмування, до небезпечного стану і навіть до тупиків - якщо процес з дуже великим запитом виявиться першим в черзі. Частково ця суперечність може бути виправленою, якщо ми допустимо часткове виділення ресурсів: запит, що стоїть в черзі першим отримує стільки ресурсів, скільки йому можна виділити, зберігаючи ситуацію безпечною, останні - віддаються наступному в черзі процесу.

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

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

Срс 7: Таблиця розташування файлів. Структура завантажувального запису dos

Таблиця розташування файлів

Таблиця розташування файлів є важливою інформаційною структурою. Вона являє собою карту (образ) області даних, у якій описується стан кожної ділянки області даних. Область даних розбивають на кластери. Кластер представляє coбою або декілька суміжних секторів у логічному дисковому адресному просторі (точніше — тільки в області даних). У таблиці FAT кластери, що належать одному файлу (некореневому каталогу), зв'язуються в ланцюжки. Для вказання номера кластера в системі керування файлами FAT-16 використовується 16-бітове слово, отже, можна мати до 2¹⁶ = 65536 кластерів (з номер 0 до 65535).

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

Таблиця 7.1 - Співвідношення між розміром розділу і розміром кластерів у FAT16

Ємність розділу, Мбайт	Кількість секторів у кластері	Розмір кластерів, Кбайт
16-127	4	2
128-255	8	4
256-511	16	8
512-1023	32	16
1024-2047	64	32

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

Логічна розбивка області даних на кластери як сукупності секторів замість використання одиночних секторів має наступний смисл:

• зменшується розмір самої таблиці FAT;

• зменшується можлива фрагментація файлів;

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

Однак, занадто великий розмір кластера веде до неефективного використання області даних, особливо у випадку великої кількості маленьких файлів. В середньому на кожний файл втрачається біля половини кластера. З табл. 7.1 слідує, що при розмірі кластера в 32 сектори (об’єм розділу — від 512 Мбайт до 1023 Мбайт), тобто 16 Кбайт, середня величина втрат на файл складе 8 Кбайт, і при числі файлів у декілька тисяч втрати можуть складати більш 100 Мбайт. Тому в сучасних файлових системах (HPFS, NTFS, FAT32 і деякі інші) розміри кластерів обмежуються (від 512 байт до 4 Кбайт). У FAT32 проблема вирішується за рахунок того, що сама FAT у цій файловій системі може вміщувати до 2²⁸ кластерів. Системи керування файлами, створені для Windows 9x і Windows NT, можуть працювати з розділами розміром до 4 Гбайт, на яких установлена система FAT, тоді як DOS з такими розділами працювати не зможе.

Ідея файлової системи з використанням таблиці розміщення файлів FAT проілюстрована рис.7.1.

З цього рисунка видно, що файл з ім'ям MYFILE.TXT розміщується, починаючи з восьмого кластера.

Всього файл MYFILE.TXT займає 12 кластерів. Ланцюжок кластерів (chain) для даного прикладу може бути записана в такий спосіб: 8, 9, 0А, 0В, 15, 16, 17, 19, 1A, 1B, 1C, ID. Кластер з номером 18 позначений спеціальним кодом F7 як дефектний (bad), він не може бути використаний для розміщення даних.

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

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

Це приводить до значного уповільнення роботи з файлами.

Рисунок 7.1 – Основна концепція FAT

В зв’язку з тим, що FAT використовується при доступі до диска дуже інтенсивно, вона зазвичай завантажується в ОЗП (в буфери введення - виведення або кеш).

У зв'язку з важливістю FAT вона зазвичай зберігається в двох ідентичних екземплярах, другий з який безпосередньо слідує за першим. Оновлюються копії FAT одночасно. Використовується тільки перший екземпляр. Якщо він з будь-яких причин виявиться зруйнованим, то відбудеться звертання до другого екземпляра. Так, наприклад, утиліта перевірки і відновлення файлової структури ScanDisk з ОС Windows 9x при виявленні невідповідності первинної і резервної копії FAT пропонує відновити головну таблицю, використовуючи дані з копії.

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

Таблиця 7.2 - Елемент каталогу

Розмір поля даних, байт	Зміст поля
11	Ім'я файлу або каталогу
1	Атрибути файлу
1	Резервне поле
3	Час створення
2	Дата створення
2	Дата останнього доступу
2	Зарезервовано
2	Час останньої модифікації
2	Дата останньої модифікації
2	Номер початкового кластера в FAT
4	Розмір файлу

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

Рисунок 7.3 – Структура системи файлів