Дисковий кеш на основі відображуваної пам'яті

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

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

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

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

 

Дискове планування

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

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

Розглянемо три алгоритми дискового планування. Для ілюстрації роботи кожного алгоритму припускатимемо, що спочатку головка перебуває на доріжці 50, після чого їй потрібно виконати запити на звертання до доріжок 90, 190, 40, 120, 0, 130, 70 і 80.

Алгоритм «першим прийшов — першим обслужений»

Найпростішим алгоритмом дискового планування є «першим прийшов — першим обслужений» (First Come - First Served, FCFS, FIFO), коли кожний запит виконують негайно після його надходження. Цей алгоритм простий у реалізації, справедливий, але недостатньо ефективний. На рис. 3.9 видно, як він спричиняє зайві переміщення головки диска.1

3. 9

 

Алгоритм «найкоротший пошук — першим»

Цей алгоритм (Shortest Seek Time First, SSTF) планує запити так, щоб першим виконувався той із них, що призводить до мінімального переміщення головки щодо її поточного положення (рис. 3.10). Цей алгоритм набагато ефективніший за FCFS-алгоритм, але не зовсім справедливий - для запитів на переміщення до крайніх доріжок диска він може спричиняти голодування.

3.10

 

Припустимо, що головка перебуває на доріжці 15 і є запити на переміщення-до доріжок 20 і 120. Відповідно до цього алгоритму першим виконують запит на переміщення до доріжки 20. Якщо за цей час у систему надійде новий запит на

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

Голодування при використанні цього алгоритму трапляється рідко, але його ймовірність зростає зі збільшенням навантаження.

Алгоритм «ліфта»

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

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

3.11

 

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

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

Розглянемо, які тут можуть виникнути проблеми.

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

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

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

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

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

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

 

Резервне копіювання

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

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

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

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

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