Незважаючи на те, що досистемне завантаження не залежить від типу операційної системи, яка починає роботу після неї, більшість систем надають власні засоби по її огранізації. У Linux найбільш популярні підсистеми завантаження LILO (LInux LOader) і GRUB (GRand Unified Bootloader). Обидві ці підсистеми мають текстовий і графічний варіанти інтерфейсу, який надає користувачеві можливість вибрати певний заздалегідь налаштований тип завантаження
Досистемне завантаження проходить в три етапи.
1.Завантажувач з ПЗУ визначає, з яких пристроїв можна грузиться і, можливо, пропонує користувачеві вибрати одне з них. Він завантажує з вибраного пристрою первинний завантажувач і передає йому управління.
2.Первинний завантажувач визначає (а найчастіше - знає), де знаходиться вторинний завантажувач - велика і досить розумна програма. Йому це зробити простіше, ніж програмі з ПЗУ: по-перше, тому що для кожного пристрою первинний завантажувач свій, а по-друге, тому що його можна легко змінювати при зміні налаштувань завантажуваної системи. У схемі, запропонованій LILO і GRUB, первинний завантажувач не вступає в розмови з користувачем, а негайно завантажує вторинний і передає йому управління.
3.Вторинний завантажувач досить розумний, щоб знати, де знаходиться ядро системи (можливо, не одне), пропонувати користувачу кілька варіантів завантаження на вибір, і навіть, в разі GRUB, дозволяє задавати власні варіанти завантаження. Його завдання - завантажити в пам'ять ядро і все необхідне для старту системи (іноді - модулі, іноді - стартовий віртуальний диск), налаштувати все це і передати управління ядру.
42. Системний етап завантаження. Реалізація системного етапу завантаження Linux.
Системний етап: реалізується ядром ОС і спеціальними процесами породженими цим самим ядром.
Ядро працює в спеціальному режимі, т. зв. «Режимі супервізора», що дозволяє йому мати доступ відразу до всієї оперативної пам'яті і апаратною таблиці задач. Процеси запускаються в «режимі користувача»: кожен жорстко прив'язаний ядром до одного запису таблиці завдань, в якій, серед інших даних, зазначено, до якої саме частини оперативної пам'яті цей процес має доступ. Ядро постійно знаходиться в пам'яті, виконуючи системні виклики - запити від процесів на виконання цих підпрограм.
Робота ядра після того, як йому передано управління, і до того, як воно почне працювати в штатному режимі, виконуючи системні виклики, зводиться до наступного.
Спочатку ядро визначає апаратне оточення. Одне і те ж ядро може бути успішно завантажено і працювати на різних комп'ютерах однаковою архітектури, але з різним набором зовнішніх пристроїв. Завдання ядра - визначити список зовнішніх пристроїв, складових комп'ютер, на який воно влучило, класифікувати їх (визначити диски, термінали, мережеві пристрої і т. п.) і, якщо треба, налаштувати. При цьому на системну консоль (зазвичай перша віртуальна консоль Linux) виводяться діагностичні повідомлення (згодом їх можна переглянути утилітою dmesg).
Потім ядро запускає кілька процесів ядра. Процес ядра - це частина ядра Linux, зареєстрована в таблиці процесів. Такому процесу можна послати сигнал і взагалі користуватися засобами між процесами взаємодії, на нього поширюється політика планувальника завдань, проте ніякої задачі в режимі користувача він не відповідає, це просто ще одна іпостась ядра. Команда ps-ef показує процеси ядра в квадратних дужках, крім того, в Linux прийнято (але не обов'язково), щоб імена таких процесів починалися на «k»: [kswapd], [keventd] і т. п.
Далі ядро підключає (монтує) кореневу файлову систему відповідно до переданих параметрів (в наших прикладах - root = / dev/hda5). Підключення це відбувається в режимі «тільки для читання» (read-only): якщо цілісність файлової системи порушена, цей режим дозволить, не посилюючи положення, прочитати і запустити утиліту fsck (file system check). Пізніше, в процесі завантаження, коренева файлова система підключиться на запис.
Нарешті, ядро запускає з файлу / sbin / init перший справжній процес. Ідентифікатор процесу (PID) у нього дорівнює одиниці, він - перший у таблиці процесів, навіть незважаючи на те, що до нього там були зареєстровані процеси ядра. Процес init - дуже, дуже старе винахід, він мало не старше самої історії (історії UNIX, звичайно), і з давніх пір його ідентифікатор дорівнює 1.
З запуску init починається завантаження самої системи
43. Процес init. Файли /etc/inittab, /etc/rc.d/rc.sysinit.
Init є батьком всіх процесів. Його головне завдання - створювати процеси за сценарієм з файлу / etc / inittab. У цьому файлі зазвичай містяться записи, що вказують init породити getty для кожної лінії, по якій користувачі можуть входити в систему. Він також контролює автономні процеси, необхідні будь-якій системі. Рівень виконання - програмна конфігурація системи, яка дозволяє існувати тільки заданій групі процесів. Процеси, що породжуються init на кожному з таких рівнів виконання, визначаються у файлі / etc / inittab.
У процесі завантаження, після ініціалізації ядра, ядро запускає / sbin / init як перший процес користувацького режиму. init відповідає за подальшу завантаження системи. Для цього він запускає так звані стартові скрипти, які виконують перевірку та монтування файлових систем, запуск необхідних демонів, налаштування ядра (у тому числі завантаження модулів ядра згідно встановленому обладнанню, настройку IP-адрес, таблиць маршрутизації та ін), запуск графічної оболонки і інші дії.
В операційних системах Unix / Linux за допомогою init можна змінити рівень ініціалізації. Рівень ініціалізації - ступінь завантаження операційної системи. Ось як відбувається ініціалізація системи: процес init запускається і аналізує файл / etc / inittab. Слід зазначити, що наведена тут система ініціалізації працює на системах Linux і Unix System V і вона дещо відрізняється від стилю ініціалізації системи в BSD-подібних системах.
За замовчуванням, в системі використано 7 рівнів ініціалізації:
0 - зупинка системи
1 - завантаження в режимі одного
2 - завантаження в многопользовательском режимі без підтримки мережі
3 - завантаження в многопользовательском режимі з підтримкою мережі
4 - не використовується
5 - завантаження в многопользовательском режимі з підтримкою мережі і графічного входу в систему
6 - перезавантаження
Набравши init n в терміналі (з правами суперкористувача), де n - номер рівня ініціалізації, можна переключитися в кожній з перерахованих вище рівнів.
Файл /etc/inittab
id:5:initdefault:
si::sysinit:/etc/rc.d/rc.sysinit
l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
x:5:respawn:/etc/X11/prefdm -nodaemon
У першому рядку описаний термінал і його конфігурація за замовчуванням. Спочатку в цьому файлі описуються рівні ініціалізації. Потім ініціюються віртуальні консолі. Запис ініціалізації консолей складається з полів, розділених двокрапкою і виглядає наступним чином:
1 - порядковий номер консолі
2345 - номери рівнів ініціалізації, для яких консоль ініціалізується
respawn - цей параметр означає, що init повинен перезапустити обслуговуючий консоль процес після виходу з сеансу або в разі краху.
/ sbin / mingetty tty6 - програма (із зазначенням параметрів), яка обслуговуватиме консоль.
Таким чином, ви легко можете створити свій рівень ініціалізації (під номером 4 або 7, 8...), просто виправивши файл / etc / inittab і створивши необхідні посилання в каталозі / etc / rc.d / rc *. D
44. Сценарії ініціалізації ОС. Приклади системних демонів.
В процесі ініціалізації можна виділити кілька етапів:
1) Розпізнавання і конфігурування пристроєм, ініціалізація драйверів і авто конфігурація ядра
2) Визначення і монтування кореневої файлової системи
3) Запуск основних системних демонів
4) Виконання ініціалізацій них сценаріїв
5) Запуск менеджерів дисплею і терміналів
Демон - це завдання, що виконується у фоновому режимі, і при запуску машини стартує ціла маленька армія таких. Бувають демони управління автоматизованими завданнями, демони для управління живленням і параметрами CPU, демони для друку і демони для ведення системних журналів. Деякі видають своє походження, додаючи до імен букву «d», інші воліють назви-ребуси навроде «binfmpt-support» або «brltty».
Демони, безсумнівно, невід'ємна частиною робочого оточення. Але є з ними і проблема. Без божественного осяяння звичайному дистрибутива Linux в точності не вгадати, які демони вам знадобляться, а які ні - в результаті всі вони норовлять перестрахуватися, аж до курйозів. Наприклад, ваш настільний комп'ютер може отримати демона управління живленням ноутбука або демона Bluetooth; працевлаштування обом не світить, але вони будуть завантажуватися і поїдати цінну пам'ять. Час завантаження і витрата пам'яті можна зменшити, трохи попрацювавши над відсіченням ваших демонів і їх підгонкою під свої вимоги. Весь фокус у тому, що саме потрібно видаляти.
Говорячи про демонів, більшість має на увазі сервіси. Часто вони стартують при завантаженні і скромно виконуються у фоновому режимі - але це не обов'язково легковагі засоби управління системою. Немає причин не вважати демонами і повні пакети додатків. Які сервіси виконувати, а які - ні, цілком залежить від вашого дистрибутива і цілей його застосування. Якщо ви використовуєте дистрибутив, орієнтований на серверне застосування, то досить імовірно, що в числі демонів буде web-сервер Apache разом зі своєю школою додатків-помічників. Це безпардонна побір ваших ресурсів, якщо web-сервер вам ні до чого, адже ще не так давно дистрибутиви типу Mandriva встановлювали і запускали web-сервер за замовчуванням. В наші кризові часи, швидше за все, такого не відбувається, але дуже ймовірно, що у вас все ще залишається небудь непотрібне, «крутиться» у фоновому режимі.
Приклади демонів: AppArmor, Apport, Avahi-deamon, Bluetooth, CUPS, GPM, KLogd, NTP, Powersaver, Powernowd, Laptop-mode.
45. Командний інтерпретатор. Базовий синтаксис команд. Шаблони вибору імен файлів.
46. Багатозадачність. Види реалізації багатозадачності.
47. Операційне середовище користувача та прикладних програм. Основні елементи операційного середовища. Організація сеансу роботи користувача через інтерфейс командного рядка.
48. Інструментальні засоби програмування. Основні відомості про мови програмування.
49. Загальні відомості про особливості розробки командних сценаріїв та програм на мові, що передбачає компіляцію.
Першою фазою є стадія компіляції, коли файли з вихідними текстами програми, включаючи файли заголовків, обробляються компілятором gсс (1). Параметри компіляції задаються або з допомогою файлу makefile, або явним зазначенням необхідних опцій компілятора в командному рядку. У підсумку компілятор створює набір проміжних об'єктних файлів. Традиційно імена створених об'єктних файлів мають суфікс «.о».
На наступній стадії ці файли за допомогою редактора зв'язків id зв'язується один з одним і з різними бібліотеками, включаючи стандартну бібліотеку за замовчуванням і бібліотеки, зазначені користувачем в якості параметрів. При цьому редактор зв'язків може виконуватися в двох режимах: статичному та динамічному, що задається відповідними опціями. У статичному, найбільш традиційному режимі зв'язуються всі об'єктні модулі і статичні бібліотеки (їх імена мають суфікс «.а»), проводиться дозвіл всіх зовнішніх посилань модулів і створюється єдиний виконуваний файл, що містить весь необхідний для виконання код. У другому випадку, редактор зв'язків по можливості підключає
спільні бібліотеки (імена цих бібліотек мають суфікс «.so»).В результаті створюється виконуваний файл, до якого в процесі запуску на виконання будуть підключені всі поділювані об'єкти. В обох випадках за умовчанням створюється виконуваний файл з ім'ям a.out
Для простих завдань усі фази автоматично виконуються викликом команди:
$ make prog або еквівалентній їй $ cc –o prog prog.c
які створюють виконуваний файл з ім'ям prog. У цьому випадку замовчуване ім'я виконуваного файлу(a.out) змінено на prog за допомогою опції –о.
Втім, вказані стадії можна виконувати і роздільно, з використанням команд сс і id. Зауважимо, що насправді команда cc являється програмною оболонкою і компілятора і редактора зв'язків, яку і рекомендується використовувати при створенні програм.
Проілюструємо процес створення більш складної програми за допомогою конкретних викликів команд.
$ cc –c file1. c file2.c Створимо проміжні об'єктні файли file1.o і file2.o
$ cc –o prog file1.o file2.o -lnsl Створимо виконуваний файл з ім'ям
prog, використовуючи проміжні об'єктні файли і бібліотеку або libnsl.a або libnsl.so
В оболонку вбудована мова програмування (командний мова), Що дозволяє писати складні командні сценарії. Саме командна мова відділяє оболонки один від одного, и саме з нього виходять користувачі, вибираючи оболонки
Linux є Unix-подібної ОС. Спочатку ОС Linux Була розроблено Лінусом Торвальдсом (Linus Torvalds) в університеті Хельсінкі (Фінляндія) на Основі ОС Minix - маленька UNIX-система, створ Andry Tanenbaum. Ранній Розвиток Linux насамперед Було пов'язано з проблемою перемикань Завдання в захіщеному режимі для 80386. І Лінус "ставши серйозно обдумувати маніакальну ідею, Як Зробити Minix краще собі самого".
Командна оболонка в системах UNIX-Вже існувала, Це Була оболонка "Bourne shell" (shell Баурна або просто shell). Трохи пізніше в UNIX-системах розробили оболонку C shell, Яка використовує Інший синтаксис,трохи нагадує синтаксис мови програмування Сі.
50. Компіляція та компоновка. Основні прийоми розробки початкових текстів, компіляції і компоновки програм. Статична компоновка. Динамічне зв’язування.
Компіляція — це процес перетворення початкової програми у виконувану. Процес компіляції складається з двох етапів. На першому етапі виконується перевірка тексту програми на відсутність помилок, на другому — генерується виконувана програма (ехе-файл).
Компоновка - приймає на вхід один або кілька об'єктних модулів і збирає у виконуваний модуль.
Для зв'язування модулів компонувальник використовує таблиці імен ідентифікаторів, створені компілятором в кожному з об'єктних модулів. Такі імена можуть бути двох типів:
· Певні або експортовані назви функцій та змінних, визначені в даному модулі і надані для використання іншим модулям.
· Невизначені або імпортовані імена - функції та змінні, на які посилається модуль, але не визначає їх в середині себе
Для динамічного зв’язування використовуються так звані віртуальні методи. Віртуальний метод визначають у деякій ієрархії класів так, щоб в усіх описах цього методу кількість та типи параметрів співпадали.
Наявність віртуальних методів у класі (а отже, динамічного зв’язування) обумовлює необхідність ініціалізації всіх об’єктів цього класу. Така ініціалізація здійснюється спеціальними методами, які називають конструкторами. Конструктор повинен викликатись раніше, ніж будь які інші дії над об’єктом класу. Клас може мати декілька конструкторів, наприклад, клас File може мати конструктор Create для створення нового файлу та конструктор Open для відкриття існуючого.
Однак у динамічного зв'язування є недоліки, наприклад, додаткові накладні витрати (тимчасові витрати) на експорт та імпорт інтерфейсів. Величина цих витрат може бути значною, тому що багато клієнтські процеси існують короткий час, а при кожному старті процесу процедура імпорту інтерфейсу повинна бути знову виконана. Крім того, у великих розподілених системах може бути вузьким місцем програма binder, а створення декількох програм аналогічного призначення також збільшує накладні витрати на створення і синхронізацію процесів.
Статичне компонування дозволяє покращити переносимість програм, а динамічне дозволяє зменшити розмір програм.
51. Створення та підключення бібліотек. Види бібліотек. Управління вибором способу підключення бібліотек, наявних у двох варіантах.
З точки зору комп'ютерних наук бібліотеки діляться на статичні та динамічні.
Статичні бібліотеки можуть бути у вигляді початкового тексту, що підключається програмістом до своєї програми на етапі написання (наприклад, для мови Fortran існує величезна кількість бібліотек для вирішення різних завдань саме в початкових текстах), або у вигляді об'єктних файлів, що приєднуються (лінкуються) до виконуваної програми на етапі компіляції (у Microsoft Windows такі файли мають розширення.lib, у UNIX-подібніх ОС — зазвичай.a). В результаті програма включає всі необхідні функції, що робить її автономною, але збільшує розмір.
Динамічні бібліотеки Також називаються розподілюваними бібліотеками (англ. shared library), або бібліотеками, що динамічно підключаються (англ. Dynamic Link Library, DLL). Це окремі файли, що надають програмі набір використовуваних функцій для завантажування на етапі виконання при зверненні програми до ОС із заявкою на виконання функції з бібліотеки. Якщо необхідна бібліотека вже завантажена в оперативну пам'ять, програма використуватиме завантажену копію бібліотеки. Такий підхід дозволяє зекономити час і пам'ять, оскільки декілька програм використовують одну копію бібліотеки, вже завантажену в пам'ять.
Динамічні бібліотеки зберігаються зазвичай у визначеному місці й мають стандартне розширення. Наприклад, файли.library у логічному томі Libs: у AmigaOS; у Microsoft Windows і OS/2 файли бібліотек загального користування мають розширення.dll; у UNIX-подібних ОС — зазвичай.so; у MacOS —.dylib.
З зошита»»»»»
Утиліта для управління статичними бібліотеками – ar.
Заходимо в каталог ~/SPOS/clib/exemple.1
1-й стан – відкомпілювати створений об’єктний файл
gcc –c test1.c test2.c
2) об’єднаємо наші об’єктні файли arc r libtest.a test1.o test2.o library.a(назва бібліотеки)
3) з файлу app.c також робимо об’єктний файл
gcc –c app.c => app.o
Статичну бібліотеку можна підключити до програми, напр. за допомогою опції l test компілятора gcc
4) скомпонувати бібліотеку: виконуваний файл
gcc –o app app.o –L. –ltest
–L. – вказує, як бібліотеку потрібно шукати в поточному каталозі.
Результат – утворення виконуваного файлу./app
Для того щоб створити дин.звязану бібл.. треба спеціальним чином скомпонувати її складові об’єктні файли
gcc –c –fPIC test1.c test2.c
–fPIC - для компіляції об’єктних файлів
2) gcc –c app.c => app.o - робимо обєктний файл з application.c
3) gcc –shared –fPIC –o libtest.so test1.o test2.o компоновка
–shared – опція викор для створення дин.звяз.бібл.
4) gcc –o app app.o –L. –ltest – не запуститься, бо не знає де знайти бібліотеку. Тому ми надаємо змінній оточення певне значення, а саме наш поточний каталог(.)
export LD_LIBRARY_PATH=.
echo $ LD_LIBRARY_PATH
52. Види бібліотек та порядок створення бібліотек.
Бібліотека — збірка об'єктів чи підпрограм для вирішення близьких за тематикою задач. Бібліотеки містять первинний код та дані, допоміжні для задіяння та інтеграції нових можливостей в програмні рішення.
Бібліотека може означати те саме, що модуль, або декілька модулів.
З точки зору комп'ютерних наук бібліотеки діляться на статичні та динамічні.
Статичні бібліотеки можуть бути у вигляді початкового тексту, що підключається програмістом до своєї програми на етапі написання (наприклад, для мови Fortran існує величезна кількість бібліотек для вирішення різних завдань саме в початкових текстах), або у вигляді об'єктних файлів, що приєднуються (лінкуються) до виконуваної програми на етапі компіляції (у Microsoft Windows такі файли мають розширення.lib, у UNIX-подібніх ОС — зазвичай.a). В результаті програма включає всі необхідні функції, що робить її автономною, але збільшує розмір.
Динамічні бібліотеки Також називаються розподілюваними бібліотеками (англ. shared library), або бібліотеками, що динамічно підключаються (англ. Dynamic Link Library, DLL). Це окремі файли, що надають програмі набір використовуваних функцій для завантажування на етапі виконання при зверненні програми до ОС із заявкою на виконання функції з бібліотеки. Якщо необхідна бібліотека вже завантажена в оперативну пам'ять, програма використуватиме завантажену копію бібліотеки. Такий підхід дозволяє зекономити час і пам'ять, оскільки декілька програм використовують одну копію бібліотеки, вже завантажену в пам'ять.
Динамічні бібліотеки зберігаються зазвичай у визначеному місці й мають стандартне розширення. Наприклад, файли.library у логічному томі Libs: у AmigaOS; у Microsoft Windows і OS/2 файли бібліотек загального користування мають розширення.dll; у UNIX-подібних ОС — зазвичай.so; у MacOS —.dylib.
При написанні програми програмістові досить вказати транслятору мови програмування (компілятору або інтерпретатору), що слід підключити таку-от бібліотеку і використовувати таку-от функцію зі вказаної бібліотеки. Ні початковий текст, ні виконуваний код функції до складу програми не входить.
53. Поняття файлу та файлової системи. Імена файлів. Символічне посилання на файл.
Сукупність каталогів і системних структур даних, що відстежують розміщення файлів на диску і вільний дисковий простір, називається файловою системою. Основною структурною одиницею будь-якої файлової системи є файл і каталог.
Фа́йлова систе́ма — спосіб організації даних, який використовується операційною системою для збереження інформації у вигляді файлів на носіях інформації. Також цим поняттям позначають сукупність файлів та директорій, які розміщуються на логічному або фізичному пристрої.
файл - це мінімальна структурована іменована послідовність даних, що зберігається на диску і займає іменовану область зовнішньої пам'яті.
Ім'я файлу. Назва файлу складається з двох частин, розділених крапкою: власне ім'я файлу і розширення, що визначає його тип (програма, дані і так далі). Власне ім'я файлу дає користувач, а тип файлу зазвичай задається програмою автоматично при його створенні. В різних операційних системах існують різні формати імен файлів.
Символічні посилання (м'які посилання) - це файли особливого типу, єдиним змістом яких є довільний рядок, який може вказувати (а може і не вказувати) на існуючий файл. Коли ви звертаєтеся до символічного посиланні в рядку або в програмі, насправді ви звертаєтеся до файлу, на який вона вказує, якщо він існує.
Символічні посилання існують завдяки тому, що вони долають кілька обмежень, властивих для (“жорстких”) посилань:
· Ви не можете створити посилання на inode в каталозі, який знаходиться в інший файловій системі. Причина проста: лічильник посилання зберігається в самому inode'і, а останній не може спільно використовуватися в різних файлових системах. А симлінки дозволяють зробити це.
· Ви не можете створити посилання на каталоги, щоб уникнути створення циклів в файловій системі. Але можете створити симлінк, який вказує на каталог, і використовувати його так, якби це насправді був каталог.
Тому символічні посилання дуже корисні у різних ситуаціях, і дуже часто люди прагнуть їх використовувати для зв'язування файлів навіть тоді, коли можна використовувати звичайне посилання. Одна з переваг звичайного зв'язування полягає в тому, що ви не втратите файл якщо видалите “оригінальний”.
54. Фізична організація файлових систем. Типи фізичної організації файлових систем. Поняття фрагментації даних.
Поняття фрагментації даних.
Основні критерії ефективності фізичної організації файлу:
швидкість доступу до даних;
об'єм адресної інформації файлу;
ступінь фрагментованості дискового простору;
можливість збільшення розміру файлу.
Фізична організація файлу описує правила розташування файлу на пристрої зовнішньої пам'яті, зокрема на диску. Файл складається з фізичних записів - блоків. Блок - найменша одиниця даних, якій зовнішній пристрій обмінюється з оперативною пам'яттю.
Безперервне розміщення - найпростіший варіант фізичної організації при якому файлу надається послідовність блоків диска, що утворять єдиний суцільний ділянку дискової пам'яті.
Для задання адреси файлу в цьому випадку досить вказати тільки номер початкового блоку. Інша перевага цього методу - простота. Але є й два істотні недоліки. По-перше, під час створення файлу заздалегідь не відома його довжина, а значить не відомо, скільки пам'яті треба зарезервувати для цього файлу, по-друге, при такому порядку розміщення неминуче виникає фрагментація, і простір на диску використовується не ефективно, так як окремі ділянки маленького розміру (мінімально 1 блок) можуть залишитися не використовуваними.
Наступний спосіб фізичної організації - розміщення у вигляді пов'язаного списку блоків дискової пам'яті. На відміну від попереднього способу, кожен блок може бути приєднаний до ланцюжок якого-небудь файлу, отже фрагментація відсутня. Файл може змінюватися під час свого існування, нарощуючи число блоків.
Фрагментація даних - процес, при якому файл при записі на диск розбивається на блоки різної довжини, які записуються в різні області жорсткого диска. Протилежним процесом є дефрагментація.
55. Типи файлів. Власники файлів. Права доступу до файлів.
В UNIX існують 6 типів файлів, що розрізняються за функціональним
призначенням та діям операційної системи при виконанні тих чи
інших операцій над файлами:
1. Звичайний файл (regular file)
2. Каталог (directory)
3. Спеціальний файл пристрою (special device file)
4. FIFO або іменований канал (named pipe)
5. Зв'язок (link)
6. Сокет
UNIX - багатокористувацька система. Щоб захистити файли кожного користувача від впливу інших
користувачів, UNIX підтримує механізм, відомий, як система прав доступу до файлів.
Файли в UNIX мають двох власників: користувача (user owner) і групу
(group owner). Важливою особливістю є те, що власник-користувач може не бути членом групи, що володіє файлом.
Власником-користувачем новоствореного файлу є користувач,
який створив файл.
Системний адміністратор може дати користувачу доступ більш, ніж до однієї групи.
Групи звичайно визначаються типами користувачів даної машини.
Права доступу підрозділяються на три типи: читання (read), запис (write) і виконання (execute). Ці типи прав
доступу можуть бути надані трьом класам користувачів: власнику файлу, групі, у котру входять власник, і усім
(іншим) користувачам.
Дозвіл на читання дозволяє користувачу читати уміст файлів, а у випадку каталогів - переглядати перелік імен
файлів у каталозі (використовуючи, наприклад, ls). Дозвіл на запис дозволяє користувачу писати у файл і змінювати його. Для каталогів це надає право створювати в каталозі нові файли і каталоги, чи видаляти файли в цьому каталозі.
Нарешті, дозвіл на виконання дозволяє користувачу виконувати файли (як бінарні програми, так і командні файли).
Дозвіл на виконання стосовно до каталогів означає можливість виконувати команди начебто cd.
56. Основні атрибути файлів.
Атрибути - це характеристики властивостей файлів. Зазвичай має такі атрибути:
1) Час створення
2) Розмір
3) Дата встановленої модифікації
4) Права доступу
Специфічно для UNIX систем:
1) тип файлу(6 типів)
2) розмір
3) права доступу
4) ідентифікатор власника користувача
5) ід. Групи власника
6) час останньої модифікації
існує ще 4 додаткових:
1) ознака примусового блокування
2) ознака липкості
3) SUID(set user ID)
4) GUID(get user ID)
Для виконуваних файлів ознака липкості вказує на те, що необхідно зберегти образ файлу в пам’яті після його виконання.
57. Призначення та приклади використання утиліт: mkdir, mknod, mkfifo, cp, mv, rename.
mkdir - створення нового каталогу. Утиліта mkdir створює каталоги, задані списком операндів, у вказаному порядку, використовуючи режим прав доступу "rwxrwxrwx'' (0777).
Синтаксис:
mkdir [-pv] [-m режим] <имя_каталога>...
Опції:
-m режим - становити права доступу кінцевого створюваного каталогу відповідно до зазначеного режимом.
-p - створювати проміжні каталоги по мірі необхідності.
-v - виводити докладну інформацію при створенні каталогів.
mknod -створює FIFO (іменований канал), спеціальний файл символьного чи блокового пристрою з вказаним ім'ям.
Синтаксис:
mknod [опції] <ім’я створюваного файлу>
Опції:
-p – створити іменовний канал FIFO.
-b – створити спеціальний блоковий файл.
-c - створити спеціальний символьний файл.
mkfifo -створює FIFO (іменовані) канали.
Синтаксис:
mkfifo [опції] <назва файлу>
Опції:
-m -встановлює права доступу до створюваних FIFO.
cp - утиліта копіювання файлу.
Синтаксис:
cp [опції] <файл | каталог> <файл | каталог >
Опції:
- R - рекурсивне копіювання;
- i - запит підтвердження перед перезаписом будь-яких файлів, які можуть бути перезаписані.
- f - протилежність -i, замінює будь-які існуючі файли без запиту підтвердження.
- v - докладний режим, повідомляє про всі дії, що виконуються cp.
Приклад: cp-i / timages / * images / - копіює всі файли з каталогу / timages / в каталог images /, що знаходиться в поточному каталозі. Запитується підтвердження, якщо має бути перезаписаний файл.
mv -команда переміщення файлів,
Синтаксис:
mv [опції] <файл|каталог>
Опції:
- f - форсування операції - попередження не виводиться, якщо перезаписується існуючий файл.
- і- протилежна дія. У користувача питається підтвердження перед перезаписом існуючого файлу.
- v-докладний режим, повідомляє про всі зміни і дії.
Приклад: mv-vf file * images / trash - переміщує без запиту підтвердження всі файли з поточного каталогу, що починаються з file, разом з усім каталогом images / в каталог trash /, і показує порядок виконання кожної операції.
rename – утиліта для перейменування файлів
58. Типи користувачів. Облікові даних користувачів. Групи користувачів.
Користувач - об'єкт, який має певні правами, може запускати на виконання програми та володіти файлами. В якості користувачів можуть, наприклад, виступати віддалені комп'ютери або групи користувачів з однаковими правами і функціями. Такі користувачі називаються псевдокористувачами. Вони володіють правами на певні файли системи і від їх імені запускаються задачі, що забезпечують ту чи іншу функціональність UNIX.
Кожен користувач має свій ID ідентифікатор:
0 – має root (суперкористувач);
1-500 – це псевдо користувачі.
Обліковий запис користувача – це відомості, якими користувач представлений в ОС. Обліковий запис користувача містить такі атрибути: логін, пароль, числовий ідентифікатор UID, первинний груповий ідентифікатор GID, ім’я домашнього каталогу, ім’я початкового командного інтерпретатора /bin/bash.
Кожен користувач системи має унікальне ім'я. Однак система розрізняє користувачів щодо асоційованого з ім'ям ідентифікатору користувача або UID.
Користувач є членом однієї або декількох груп - списків користувачів, що мають подібні завдання. Приналежність до групи визначає додаткові права, якими володіють всі користувачі групи. Кожна група має унікальне ім'я, але як і для користувача, внутрішнім поданням групи є її ідентифікатор GID.
UID і GID визначають, якими правами володіє користувач в системі.
Вся інформація про користувачів зберігається у файлі etc/passwd. Це звичайний текстовий файл, право на читання якого мають всі користувачі системи, а право на запис має тільки адміністратор.
Аналогічно, інформація про групи зберігається у файлі / etc / group і містить списки користувачів, які належать тій чи іншій групі.
59. Призначення та зміст файлів, що утворюють традиційну базу обліку користувачів Unix. Псевдокористувачі.
Файли, що утворюють традиційну базу обліку користувачів Unix:
1. etc/passwd - містить ідентифікатор та атрибути користувачів.
Атрибути: логін, пароль, числовий ідентифікатор UID, первинний груповий ідентифікатор GID, ім’я домашнього каталогу, ім’я початкового командного інтерпретатора /bin/bash.
2. etc/group - містить ідентифікатор та атрибути груп користувачів.
Атрибути:
1. ім’я групи;
2. зашифрований пароль раніше, а зараз він Х – затінений; 3. Ідентифікатор групи;
4. список членів групи.
3. etc/shadow – містить зашифровані паролі користувачів. Це текстовий файл, кожен окремий рядок якого містить інформацію про одного користувача, переглядати яку може тільки root.
Атрибути: login, зашифрований пароль користувача, дата останньої зміни пароля користувача, мінімальна та максимальна кількість днів до зміни пароля користувача, дата закінчення терміну дії облікового запису.
4. etc/gshadow -містить зашифровані паролі групи користувачів.
Атрибути:
1. ім’я групи;
2. зашифрований пароль, якщо на початку пароля стоїть "!", то група заблокована для приєднання;
3. список адміністраторів групи;
4. список користувачів.
Псевдокористувач – це такий користувач, який без права входу в систему має в своєму розпорядженні відповідні процеси для кожного аспекту, пов’язаного з приналежністю системи. Вони володіють правами на певні файли системи і від їх імені запускаються задачі, що забезпечують ту чи іншу функціональність UNIX.
60. Призначення та приклади застосування базових утиліт управління обліком користувачів Unix: useradd, usermod, userdel, groupadd.
Б азові утиліти управління обліком користувачів Unix:
useradd – призначена для реєстрації користувача, додати нового користувача.
usermod – призначена для модифікації облікових даних користувачів.
userdel – призначена для видалення користувача.
groupadd – призначена для створення нової групи користувачів.
61. Призначення та приклади застосування базових утиліт управління обліком користувачів Unix: groupmod, groupdel, passwd, gpasswd.
- groupmod _name – утиліта для редагування
інформації про групу користувачів у системі.
Пр-д:
groupmod group1 –n group2 – змінити ім’я group1на group2.
- groupdel _name – утиліта для видалення групи з системи.
Пр.-д:
groupdel group1 – видалить group1 з системи.
- passwd _user – утиліта для зміни/встановлення пароля для користувача user.
-l – блокування облікового запису
-d – видалення пароля облікового запису
-f– встановлення дати позбавлення повноважень
-n – мінімальний час дії пароля в днях
-x – максимальний час дії пароля в днях
-S – виведення повідомлення про статус користувача
- gpasswd _group – змінює/встановлює пароль для групи group.
Пр-д:
gpasswd gr1 password – встановити пароль password для группи gr1.
62. Програма, задача, процес. Привілейовані та непривілейовані процеси.
Процес – це об’єкт Linux, котрий складається з адресного простору пам’яті і набору структур даних. Запущена на виконання програма або служба.
Запит на ресурси системи і комп’ютера.
Програма – це деяка послідовність машинних команд, що зберігається на диску, в разі необхідності завантажується у пам'ять і виконується. Під час виконання програму представляє процес.
Процеси бувають активними (привілейованими), фоновими(непривілейованими) та відкладеними. В кожний момент часу може бути лише один активний процес. Активним є такий процес, з яким безпосередньо взаємодіє користувач, тобто тільки цей процес отримує інформацію з клавіатури і посилає результати на ваш екран (як кажуть, виконується на передньому плані). З іншого боку, фонові процеси не одержують інформації з термінала, у загальному випадку вони спокійно виконуються, не вимагаючи потреби в спілкуванні з користувачем.
63. Ідентифікатор процесу. Родинні відносини між процесами.
Ідентифікатор процесу (PID). Кожен процес в системі має унікальний ідентифікатор. Кожен новий запущений процес отримує номер на одиницю більше попереднього.
Ідентифікатор батьківського процесу (PPID). Даний атрибут процес отримує під час свого запуску і використовується для отримання статусу батьківського процесу.
В UNIX, кожен процес, окрім процесу 0 (swapper) створюється коли інший процес виконує системний виклик fork. Процес, що викликає fork називають батьківським процесом, а новостворений процес — дочірнім процесом. Кожен процес, (окрім процесу 0) має один батьківський процес, але може мати багато дочірніх.
64. Призначення та приклади застосування базових утиліт управління задачами Unix: ps, kill, nice, renice, su, sudo.
- Ps – вивести поточні активні процеси
-a - пов'язані з конкретним терміналом, крім головних системних процесів сеансу
-x - процеси, від'єднані від терміналу (демони, служби)
-u - відображення користувача (власника процесу)
-u user - відобразити процеси користувача user
- kill pid - вбити процес з id pid
-TERM pid - спробувати завершити процес з pid - сигналом SIGTERM (цей сигнал може бути оброблений або проігнорований програмою).
-KILL pid - Завершити процес примусово, вбити процес в незалежності від його стану сигналом SIGKILL (процес не може проігнорувати сигнал).
- nice -n value script - зміна пріоритету процесу, що запускається, script на значення, рівне value (може бути від -20 до 19, в порядку зменшення пріоритету, тобто -20 - найвищий).
- renice -value PID - зміна пріоритету запущених процесів з PID = PID на значення, рівне value (може бути від -20 до 19, в порядку зменшення пріоритету, тобто -20 - найвищий)
- su user - створення оболонки (подоболочки поточної оболонки) з правами користувача user (без зазначення користувача - викликається оболонка root)
-,-L, - login - всі 3 параметри мають одне значення - завантажити оточення викликається користувача (виконуються всі стартові сценарії і підвантажуються змінні оточення викликається користувача)
-с command - виконати команду command з правами суперкористувача і "понизити" права в вихідні після завершення команди.
65. Поняття мережевої та розподіленої ОС. Вимоги до розподілених ОС.
Залежно від того, який віртуальний образ створює операційна система для того, щоб підмінити їм реальну апаратуру комп'ютерної мережі, розрізняють мережеві ОС і розподілені ОС.
Мережева ОС надає користувачеві якусь віртуальну обчислювальну систему, працювати з якою набагато простіше, ніж з реальною мережевою апаратурою. В той же час ця віртуальна система не повністю приховує розподілену природу свого реального прототипу, тобто є віртуальною мережею.
Мережева ОС. Працюючи в середовищі мережевої ОС, користувач хоча і може запустити завдання на будь-якій машині комп'ютерної мережі, завжди знає, на якій машині виконується його завдання. За умовчанням призначене для користувача завдання виконується на тій машині, на якій користувач зробив логічний вхід. Якщо ж він хоче виконати завдання на іншій машині, то йому потрібно або виконати логічний вхід в цю машину, використовуючи команду типу remote login, або ввести спеціальну команду віддаленого виконання, в якій він повинен вказати інформацію, що ідентифікує віддалений комп'ютер.
Термін «мережева операційна система» використовується в двох значеннях: по-перше, як сукупність ОС всіх комп'ютерів мережі і, по-друге, як операційна система окремого комп'ютера, здатного працювати в мережі.
Розподілена ОС. Магістральним напрямом розвитку мережевих ОС є досягнення якомога вищого ступеня прозорості мережевих ресурсів. У ідеальному випадку мережева ОС повинна пре-дставити користувачеві мережеві ресурси у вигляді ресурсів єдиної централізованої віртуальної машини. Для такої операційної системи використовують спеціальну назву — розподілена ОС, або істинно розподілена ОС.
Розподілена ОС, динамічно і автоматично розпо-діляючи роботи по різних машинах системи для обробки, примушує набір мережевих машин працювати як віртуальний уніпроцесор. Користувач розподіленої ОС не має відомостей про те, на якій машині виконується його робота. Розподілена ОС існує як єдина операційна система в масштабах обчислювальної системи.
Кожен комп'ютер мережі, що працює під управлінням розподіленою ОС, виконує частину функцій цієї глобальної ОС. Розподілена ОС об'єднує всі комп'ютери мережі в тому сенсі, що вони працюють в тісній кооперації один з одним для ефективного використання всіх ресурсів комп'ютерної мережі.
Природним вимогою до будь-якої розподіленої ОС є забезпечення зручного, ефективного і надійного доступу до ресурсів комп’ютерної мережі.
Характерними ознаками розподіленої організації ОС є: наявність єдиної довідкової служби поділюваних ресурсів, єдиної служби часу, використання механізму виклику віддалених процедур (RPC) для прозорого розподілу програмних процедур по машинах, багатониткової обробки, що дозволяє розпаралелювати обчислення в рамках однієї задачі і виконувати цю задачу відразу на декількох комп'ютерах мережі, а також наявність інших розподілених служб.
66. Поняття обчислювального кластера. Розподілена подільна пам’ять.
Обчислювальні кластери призначені для виконання паралельних програм, що описують вирішення складних наукових проблем (розшифрування генома, синтезу молекул тощо). Багато з них сьогодні потребують обчислювальних потужностей, яких неможливо досягти у разі використання окремих комп'ютерів. Фактично, такий кластер — це аналог багатопроцесорного суперкомп'ютера, але при цьому коштує значно дешевше. Більшу частину наукових обчислювальних задач у наш час розв'язують на таких кластерах.
Традиційно розподілені обчислення базуються на моделі передачі повідомлень, в якій дані передаються від процесора до процесора у вигляді повідомлень. Віддалений виклик процедур фактично є тією ж самою моделлю (або дуже близькою).
DSM (Distributed Shared Memory - Розподілена подільна пам’ять) - віртуальний адресний простір, який поділяється всіма вузлами (процесорами) розподіленої системи. Програми отримують доступ до даних в DSM приблизно так само, як вони працюють з даними у віртуальній пам'яті традиційних ЕОМ. У системах з DSM дані переміщаються між локальною пам'яттю різних комп'ютерів аналогічно тому, як вони переміщаються між оперативною і зовнішньою пам'яттю одного комп'ютера.
67. Принципи та обмеження основних способів оповіщення задач про настання подій (синхронізації).
Процес оповіщення про настання події складається з двох етапів:
1. Генерація сигналу;
При настанні події ОС генерує сигнал: в структурі TASK_STRUCT вона зводить відповідний біт у масці надійшовших сигналів.
2. Обробка сигналу;
Після установки біта процес повинен обробити цей сигнал. Процес не може обробити сигнал миттєво, він робить це тільки в певні моменти часу:
• з черги готових процес вибирається на виконання диспетчером (очікуючи в черзі, процес не може отримати сигнал);
• перед блокуванням;
• під час блокування, якщо блокування є перериваючою (наприклад, очікування введення з клавіатури); якщо той же read читає з диска, а не з клавіатури, то таке блокування є непрериваючим.
Кожен сигнал володіє дією за замовчуванням. Ця дія виконується ОС, якщо процес не встановить для цього сигналу іншу дію. Усього існують 5 дій за замовчуванням:
1) аварійне завершення з дампом пам'яті (D);
2) завершення без дампа (A);
3) ігнорування сигналу (I);
4) зупинка (процес може бути припинений) (S);
5) продовження (С)
Майже для кожного з сигналів процес може перевизначити дії, що виконуються за замовчуванням. Оброблювач можна перевизначити для будь-яких сигналів, крім двох:
• SIGKILL (це завжди зняття - реакція 2)
• SIGSTOP - переклад процесу в призупинене стан.
альтернативи:
• Ігнорувати сигнал;
• Визначити свій обробник сигналу.
68. Основні програмні інтерфейси синхронізації виконання процесів.
Програмний інтерфейс керування процесами
Win32
З введенням потокової багатозадачності виникла необхідність у спеціальному механізмі, званому синхронізацією. Синхронізація дозволяє контролювати виконання потоків (і процесів) строго певним чином. У Win32 для синхронізації виділена ціла підсистема. Бібліотека класів MFC повністю підтримує засоби багатозадачності.
У MFC механізм синхронізації, забезпечуваний інтерфейсом Win32, підтримується за допомогою наступних класів, породжених від класу CSyncObject:
• CCriticalSection - реалізує критичний розділ.
• CEvent - реалізує об'єкт події
• CMutex - реалізує виключає семафор.
• CSemaphore - реалізує класичний семафор.
69. Командний сценарій. Потоки введення/виведення, конвеєри.
Потоки введення/виведення в системах типу UNIX (і багато інших) - потоки процесу, що мають номер (дескриптор), зарезервований для виконання деяких «стандартних» функцій. Як правило (хоча і не обов'язково), ці дескриптори вже відкриті в момент запуску завдання.
Стандартне введення
Потік номер 0 (stdin) зарезервовано для читання команд користувача або вхідних даних.
При інтерактивному запуску програми за замовчуванням stdin націлений на читання з пристрою текстового інтерфейсу користувача (клавіатури). Командна оболонка UNIX (і оболонки інших систем) дозволяють змінювати введення цього потоку за допомогою символу «<». Системні програми (демони тощо), як правило, не користуються цим потоком.
Стандартне виведення
Потік номер 1 (stdout) зарезервовано для виведення даних, як правило (хоча і не обов'язково) текстових.
При інтерактивному запуску програми stdout за замовчуванням націлений на запис на пристрій виведення (монітор). Командна оболонка UNIX (і оболонки інших систем) дозволяють скерувати цей потік за допомогою символу «>». Для виконання програм у фоновому режимі цей потік зазвичай переводять у файл.
В Юнікс-подібних операційних системах, конвеєри відповідають оригінальним конвеєрам програм: набір процесів, зв'язані своїми стандартними потоками вводу-виводу таким чином, що вихідний потік кожного процесу (stdout) безпосередньо зв'язується зі стандартним потоком вводу (stdin) наступного. Кожний зв'язок реалізується як анонімний конвеєр. Програми-фільтри часто використовуються в подібнх комбінаціях. Цю концепцію було запропоновано Дугласом Мак-Ілроєм для оболонок Юнікс і дано назву за аналогією зі справжніми конвеєрами.
В більшості Юнікс-подібних операційних системах, процеси конвеєра запускаються одночасно та їхні стандартні потоки зв'язуються, всі ці процеси керуються ядром операційної системи разом із іншими процесами. Важливою особливістю реалізації конвеєрів на Юніксах, є застосування буферизації під час передачі даних. Завдяки буферізації, записування та зчитування даних в конвеєр може відбуватись із різною швидкістю, без втрати даних.
70. Приклади застосування операторів перенаправлення введення/виведення та конвеєрів.
Однією з найкорисніших фундаментальних властивостей Unix (у тому числі й Linux) є конвеєри. Конвеєри уможливлюють зв'язок між процесами, котрі не призначались спеціально для такої взаємодії. А це дозволяє знаряддям з досить вузьким колом функцій комбінуватись у різні способи для виконання складніших завдань.
Простий приклад використання конвеєра:
ls | grep x
Оболонка bash, перевіряючи командний рядок, знаходить вертикальну риску |, що розділює дві команди, після чого, як і інші оболонки, запускає обидві команди, під'єднуючи вивід першої команди до вводу другої. Програма ls видає список файлів у поточному каталозі, тоді як grep читає вивід ls й видруковує лише ті лінії, які містять x.
Наведений приклад, відомий більшості користувачів Unix, є так званим "неназваним конвеєром". Такий конвеєр існує лише в ядрі й недоступний для процесів, що його створили — в даному випадку це оболонка bash. Кому невідомо: головний процес — це перший процес, створений програмою. Він може, в свою чергу, створювати підпроцеси.
Перенаправлення потоків введення-виведення здійснюється, подібно DOS за допомогою символів:
> - перенаправлення стандартного потоку виводу >> - перенаправлення стандартного потоку виводу у режимі записування < - перенаправлення стандартного потоку вводу << - отримання дані зі стандартного потоку вводу до тих пір, поки не зустрінеться розділювач Однак, на відміну від DOS при створенні програмного каналу між двома процесами в ОС UNIX/Linux запускає обидва процесу одночасно і здійснює передачу інформації через системний буфер (без проміжної запису на диск). Таким чином, програмні канали в ОС UNIX/Linux є дуже ефективним способом обміну. У разі ппереполнения системного буфера (наприклад, якщо `передавальна"" програма видає інформацію в канал швидше, ніж її може обробити `приймаюча"" програма) ОС автоматично припиняє той процес, який здійснює запис у канал до звільнення буфера.