Мал. 6.25.1-вузли, розміщені на початку диска (а); диск, розділений на групи циліндрів, кожна зі своїми власними блоками і і-вузлами (б)
Один із способів збільшення продуктивності полягає у встановленні і-вузлів в середину диска, зменшуючи, таким чином, середню відстань переміщення блоків голівок в два рази. Інша ідея, показана на мал. 2.25, би, полягає в розбитті диска на групи циліндрів, кожна зі своїми і-вузлами, блоками і списком вільних блоків [230]. Коли створюється новий файл, може бути вибраний будь-кому і-вузол, але робиться спроба знайти блок в тій же групі циліндрів, що і і-вузол. Якщо ця спроба закінчується невдачею, використовується блок в сусідній групі циліндрів.
Файлові системи з журнальною структурою LFS
Зміни в технології чинять вплив на сучасні файлові системи. Зокрема, центральні процесори стають все швидше, місткість дисків збільшується, ціна їх знижується (але швидкість їх збільшується не так сильно), а розміри оперативної пам'яті ростуть експоненціально. Єдиним параметром, не зростаючим так нестримно, є час пошуку циліндра диска. В результаті в багатьох файлових системах з'являється вузьке місце. В університеті Берклі були проведені дослідження, спрямовані на зниження осту-роти цієї проблеми за допомогою створення абсолютно нової файлової системи LFS (Log - structured File System - файлова система з журнальною структурою). У цьому розділі ми коротко опишемо, як працює система LFS. Додаткові відомості можна упізнати в [280].
У основі системи LFS лежить ідея того, що у міру прискорення центральних процесорів і збільшення розмірів оперативної пам'яті кешування дисків стає все вигідніше. Тому стає можливим задовольнити дуже істотну частину усіх дискових запитів прямо з кеша файлової системи без звернення до диска. З цього виходить, що в майбутньому більшість звернень до диска складатимуть звернення запису, тому алгоритм випереджаючого читання, що застосовувався в деяких файлових системах, вже не дає великого виграшу продуктивності.
Ситуація ускладнюється тим, що в більшості файлових систем операції записи виконуються дуже маленькими блоками даних. Такі операції запису виявляються украй неефективними, оскільки самому запису, що займає 50 мкс, часто передує пошук циліндра протягом 10 мс і затримка 4-мілісекунди обертання. При таких параметрах ефективність диска падає до 1 %.
Щоб зрозуміти, з чого складаються усі ці дрібні операції запису, роздивимось створення файлу в операційній системі UNIX. Для запису у файл необхідно провести операції запису в i-вузол каталогу, блок каталогу, i-вузол файлу і, нарешті, блок самого файлу. В принципі ці операції запису можуть бути відкладені на деякий час, але при цьому можуть виникнути серйозні проблеми з несуперечністю файлової системи у разі збою комп'ютера перш, ніж буде виконаний запис на диск. З цієї причини i-вузли зазвичай записуються на диск без зволікання.
Враховуючи усе вищесказане, розробники файлової системи LFS вирішили реалізувати файлову систему UNIX так, щоб досягти максимуму ефективності використання диска, незважаючи на робоче навантаження, що складається з великої кількості випадкових дрібних операцій запису. Задум полягає у використанні диска як журналу. Періодично, коли виникає необхідність, усі блоки, що буферизують в пам'яті, які мають бути записані, збираються разом в єдиний сегмент, і він записується на диск одним неперервним шматком в кінець журналу. Записуваний сегмент може містити i-вузли, блоки каталогів і блоки даних, перемішаних один з одним. На початку кожного сегменту створюється зміст сегменту. Якщо довести середній розмір сегменту до 1 Мбайт, то можна використовувати майже усю пропускну спроможність диска.
При такій організації i-вузли існують і мають ту ж структуру, що і в UNIX, але тепер вони, замість того щоб розташовуватися у фіксованій позиції на диску, перемішані по усьому журналу. Проте, коли програма знаходить i-вузол, визначення розташування блоків виконується звичайним способом. Звичайно, тепер виявити i-вузол набагато складніше, оскільки його адреса не визначається по його номеру, як це було в UNIX. Щоб можна було знайти i-вузол, створюється масив i-вузлів, індексований по i -номерам. Елемент г масиву вказує на i-вузол i на диску. Масив зберігається на диску, але також міститься і в кеші, так що найбільш часто використовувані частини цього масиву постійно знаходяться в оперативній пам'яті.
Таким чином, усі операції запису буферизуються в пам'яті, і періодично дані з буфера записуються на диск у вигляді єдиних сегментів в кінець журналу. Щоб відкрити файл, використовується масив, що дозволяє виявити i-вузол у файлі. Як тільки i-вузол виявлений, можуть бути визначені номери блоків файлу. Усі ці блоки також розташовуються в сегментах десь в журналі.
Якби диски були нескінченного розміру, на цьому усе б і закінчувалося. Проте існуючі диски мають обмежений розмір, тому рано або пізно журнал займе увесь диск. На щастя, багато сегментів можуть містити непотрібні блоки, наприклад, якщо файл був перезаписаний, його i-вузол буде вказувати на нові блоки, але старі блоки будуть усе також займати місце в записаних раніше сегментах.
Для вирішення проблеми повторного використання блоків в старих сегментах у файлової системи LFS є очищаючий потік, що займається постійним скануванням журналу з метою зробити його компактнішим. Він починає з того, що прочитує зміст найпершого сегменту журналу, щоб визначити, які i-вузли і файли знаходяться в нім. Потім він дивиться в поточний масив i-вузлів, перевіряючи, чи є i-вузли все ще поточними і чи використовуються все ще блоки файлів. Якщо ні, то ця інформація відкидається, а що все ще використовуються i-вузли і блоки прочитуються в пам'ять, щоб записати їх в наступний сегмент. Початковий сегмент позначається як вільний, тому журнал може використовувати його для нових даних. Таким чином, чистильник рухається по журналу, видаляючи старі сегменти з диска і поміщаючи усю цінність, що має, інформацію в пам'ять для перезапису в наступний сегмент. В результаті диск є великим кільцевим буфером, в якому потік, що пише, додає нові сегменти з одного кінця, а очищаючий процес видаляє старі сегменти з іншого.
Облік розташування блоків тут дуже нетривіальний, оскільки, коли блок файлу записується в новий сегмент, i-вузол файлу (десь в журналі) має бути знайдений, оновлений і поміщений в буфер для запису в наступний сегмент. При цьому масив i-вузлів також має бути оновлений, щоб елемент масиву вказував на нову копію. Проте адміністрування такої системи цілком можливо, а збільшення продуктивності показує, що усі ці складнощі були не марні. Приведені в цитованій вище статті результати вимірів показали, що файлова система з журнальною структурою LFS перевершує систему UNIX при множині невеликих записах на порядок, а при читанні і великих записах має схожу або кращу продуктивність.
Приклади файлових систем
У наступних розділах ми обговоримо декілька прикладів файлових систем, від досить простих до украй складних. Оскільки сучасні файлові системи UNIX і Windows 2000 описуватимуться в окремих главах цієї книги (глави 10 і 11), ми не станемо обговорювати їх тут. Замість них ми розглянемо їх попередників.
Файлові системи CD - ROM
Як перший приклад розглянемо файлову систему, вживану на CD, - ROM. Ці системи є зовсім простими, оскільки вони створювалися для носіїв, запис на які міг проводитися тільки один раз. Крім усього іншого, в цих файлових системах відсутній облік вільних блоків, оскільки файли на CD - ROM не можуть бути видалені або додані після того, як диск вже виготовлений. Нижче ми розглянемо основні типи файлових систем для CD - ROM і два варіанти розширення цих систем.
Файлова система ISO 9660
У 1988 році був прийнятий Міжнародний стандарт ISO 9660, що описує файлові системи для CD, - ROM. Що практично кожен продається сьогодні CD - ROM відповідає цьому стандарту, іноді узгоджуючись з його розширеннями, які обговорюватимуться нижче. Одне з призначень цього стандарту полягало в тому, щоб будь-який CD - ROM міг бути прочитаний на будь-якому комп'ютері, незалежно від використовуваних байтового порядку і операційної системи. Як наслідок, на файлову систему були накладені певні обмеження, які повинні були дозволити читати ці диски навіть найслабкішим з тих, що використалися тоді операційних систем (таким як MS - DOS).
У CD - ROM немає концентричних циліндрів, як у магнітних дисків. Замість цього вони містять безперервну спіраль, на якій послідовно розміщені усі біти (хоча пошук упоперек спіралі також можливий). Біти уздовж спіралі розділені на логічні блоки (також звані логічними секторами) по 2352 байт. Деякі з цих байтів використовуються для преамбул, корекції помилок і інших накладних витрат. Корисне навантаження в кожному блоці складає 2048 байт. Аудіодиски містять спеціальні розділові ділянки між композиціями, а також спеціальні заголовки і кінцевики для кожної фонограми, не використовувані в CD - ROM, що містять інші дані. Часто позиція блоку в спіралі вказується в хвилинах і секундах. Вона може бути перероблена в лінійний номер блоку, оскільки кожна секунда містить 75 блоків.
Стандарт ISO 9660 також підтримує набори розміром до 216-1 CD - ROM. Самі CD - ROM також можуть бути розділені на окремі логічні томи (розділи). Проте нижче обговорюватиметься стандарт ISO 9660 для одного CD - ROM, не розділеного на томи.
Кожен CD - ROM починається з 16 блоків, чия функція не визначається стандартом ISO 9660. Виробник CD - ROM може використовувати цю область для розміщення завантажувача операційної системи або для іншої мети. Услід міститься один блок, основний описувач тому, в якому зберігається деяка загальна інформація про CD, що містить, - ROM. Серед даних, що містяться в цьому блоці, ідентифікатор системи (32 байт), ідентифікатор тому (32 байт) ідентифікатор видавця (128 байт), і ідентифікатор особи, що підготувала дані (128 байт). Виробник диска може заповнити ці поля довільним образом, при умові, що він використовуватиме тільки символи верхнього регістра, цифри і дуже обмежену кількість розділових знаків, щоб гарантувати сумісність з різними платформами.
Основний описувач тому також містить імена трьох файлів, в яких можуть зберігатися короткий огляд, повідомлення про авторські права і бібліографічна інформація відповідно. Крім того, в цьому блоці також містяться певні ключові числа, що включають розмір логічного блоку (як правило, 2048, проте в певних випадках можуть використовуватися блоки більшого розміру, наприклад 4096, 8192 і інших мір двох), кількість блоків на CD - ROM, а також дата створення і дата закінчення терміну служби диска. Нарешті, основний описувач тому також містить описувач кореневого каталогу, що дозволяє найти цей каталог на CD - ROM (тобто визначити номер блоку, початок каталогу, що містить). Починаючи з цього каталогу, можна визначити місцезнаходження усієї іншої файлової системи.
Окрім основного описувача тому, CD - ROM - диск може містити додатковий описувач тому. У нім зберігається інформація, схожа з тією, що зберігається в основному описувачі, але ми не станемо розглядати його в цій книзі.
Кореневий каталог і усі інші каталоги можуть містити змінну кількість записів, в останній з яких встановлений спеціальний біт, мітячи цей запис як останній. Самі каталогові записи також можуть мати змінну довжину. Кожен запис містить від 10 до 12 полів, деякі з них містять текст формату ASCII, а інші є числовими двійковими полями. Двійкові поля кодуються двічі, один раз у форматі, використовуваному в процесорах типу Pentium (спочатку молодші байти, потім старші), і один раз у форма-те, використовуваному в процесорі SPARC (спочатку старші байти, потім молодші). Отже, 16-розрядне число займає 4 байт, а 32-розрядне число 8 байт. Таке надмірне кодування було використане при розробці стандарту, щоб нікого не образити. Якби стандарт враховував тільки один із способів зберігання двійкового числа, тоді співробітники компаній, в яких застосовується інший спосіб, порахували б, що їх віднесли до громадян другого сорту і не прийняли б стандарт. Таким чином., емоційний зміст CD - ROM може бути точно виміряне в кілобайтах втраченого простору.
Формат каталоговій запису стандарту ISO 9660 показаний на мал. 6.26. Оскільки каталогові записи можуть бути змінної довжини, перше поле запису представляє собою байт, що містить довжину запису. Щоб уникнути будь-якої суперечливості стандартом визначено, що старший біт цього байта розташовується ліворуч.
Мал. 6.26. Каталоговий запис стандарту ISO 9660
Записи каталогів можуть мати розширені атрибути. Якщо для каталогового запису використовується ця властивість, тоді другий байт містить довжину запису розширених атрибутів.
Услід розташовується номер початкового блоку файлу. Файли зберігаються на диску у вигляді безперервних послідовностей блоків, так що розміщення файлу на диску однозначно визначається початковим блоком і розміром, значення якого міститься в наступному полі.
У наступному полі зберігаються дата і час запису CD - ROM. Значення року, місяця, дня, години, хвилини, секунди і часової зони зберігаються в окремих байтах. Роки відлічуються від 1900, що означає, що CD - ROM страждатимуть від проблеми 2156 року, оскільки слідом за 2155 роком для них наступить 1900 рік. Виникнення цієї проблеми можна було відкласти на 88 років, прийнявши за точку відліку 1988 (рік прийняття стандарту). Якби це було зроблено, проблему можна було б відкласти до 2244 року.
Поле Flags (прапори) містить декілька різних керівників бітів, один з яких дозволяє приховувати запис при відображенні каталогу (властивість, взяте з MS - DOS), інший дозволяє використання розширених атрибутів, а третій позначає останній запис в каталозі. Ми не станемо розглядати тут інші біти цього поля. Наступне поле описує особливості чергування частин файлу на диску. Ця властивість не використовується в простій версії стандарту ISO 9660, тому воно не обговорюватиметься в цій книзі.
Ще одне поле вказує місце розташування файлу на CD - ROM. Стандарт допускає можливість розташування файлу на іншому CD - ROM набору. Таким чином, можна створити на одному CD - ROM головний каталог, що містить усі файли усіх інших CD, - ROM набору.
Поле, відмічене на мал. 6.26 символом I, містить довжину імені файлу в байтах. За ним йде само ім'я файлу, що складається з базового імені (base паті на малюнку), точки, розширення, крапки з комою і версією файлу в двійковому форма-те (один або два байти). У базовому імені і розширенні можуть використовуватися прописні символи, цифри від 0 до 9 і символ підкреслення. Усі інші символи заборонені, щоб гарантувати, що кожен комп'ютер зможе працювати з усіма файлами на диску. Базове ім'я може бути завдовжки до восьми символів; розширення - до трьох символів. Такий вибір був продиктований необхідністю сумісності з системою MS - DOS. Ім'я файлу може зустрічатися кілька разів, але з різними номерами версій.
Останні два поля не завжди є присутній. Поле Padding (заповнення) використовується для вирівнювання розміру каталогового запису до парної кількості байтів, щоб вирівняти записи в каталозі по 2-байтових межах. Якщо потрібні вирівнювання, використовується нульовий байт. Нарешті, функція і розмір останнього поля System use (Sys на малюнку) ніяк не визначаються стандартом. У стандарті вказується лише, що це поле повинне складатися з парного числа байтів. У різних операційних системах це поле використовується різним образом. Наприклад, Macintosh зберігає в цьому полі прапори Finder.
Усі записи каталогу, окрім перших двох, розташовуються в алфавітному поряд-ке. Перший запис є описувач самого каталогу. Другий запис є посиланням на батьківський каталог. У цьому сенсі ці записи аналогічні каталоговим записам "." і ".." в UNIX.
Кількість каталогових записів не обмежена. Проте існує обмеження глибини вкладеності каталогів. Максимальна глибина вкладеності каталогів рівна восьми.
Стандартом ISO 9660 визначено так звані три рівні. На рівні 1 застосовуються найжорсткіші обмеження. Імена файлів обмежуються вже описаної вище схемою 8 + 3, а імена каталогів можуть складатися з восьми символів і не можуть мати розширень. Крім того, рівень 1 вимагає, щоб усі файли були безперервними. Використання цього рівня забезпечує сумісність CD - ROM з найширшим спектром систем.
Рівень 2 послабляє обмеження на довжину імені. Він дозволяє файлам і каталогам мати імена до 31 символу, але з того ж набору символів.
На рівні 3 використовуються ті ж обмеження імен, що і на рівні 2, але послаблюється жорсткість вимоги безперервності файлів. На цьому рівні файл може складатися з декількох розділів, кожен з яких є безперервною послідовністю блоків. Одна і та ж послідовність блоків може кілька разів зустрічатися в одному файлі і навіть входити в декілька різних файлів. Така організація файлової системи дозволяє економити місце на диску.
Рок-Ридж розширення
Як було показано, стандарт ISO 9660 містить багато різних обмежень. Незабаром після виходу цього стандарту користувачі з UNIX-групи почали роботу над його розширенням, щоб файлова система UNIX могла бути представлена на CD - ROM. Ці розширення дістали назву Рок-Ридж (Rock Ridge) по місту з фільму Джина Уайлдера Blazing Saddles (Вогняні сідла), ймовірно, тому, що цей фільм подобався одному з членів комітету.
Розширення використовує поле System use, щоб CD - ROM формату Рок-Ридж міг читатися на будь-якому комп'ютері. Усі інші поля відповідають вимогам стандарту ISO 9660. Система, не знайома з розширеннями Рок-Ридж, про-сто ігнорує їх і бачить нормальний CD - ROM.
Розширення містять наступні поля:
PX – Атрибути POSIX.
PN – Старший і молодший номера пристроїв.
SL – Символьний зв’язок.
NM – Альтернативне ім’я.
CL – Місце дочірнього вузла.
PL – Місце дочірнього вузла.
RE – Перерозподілення.
TF – Тимчасові штампи.
Поле РХсодержит стандартні біти дозволів rwxrwxrwx системи UNIX для власника, групи і усіх інших. Воно також містить інші біти слова стану, такі як SETUID, SETGID і т. п.
Щоб необроблені пристрої могли бути представлені на CD - ROM, вводиться поле PN. Воно містить старший і молодший номери пристроїв, асоційованих з файлом. Таким чином, вміст каталогу /dev може бути записано на CD - ROM і пізніше правильно відтворено на іншій системі.
Поле SL використовується для символьних зв'язків. Воно дозволяє файлу з однієї файлової системи посилатися на файл з іншої файлової системи.
Ймовірно, найбільш важливим є поле NM. З його допомогою можна вказати для файлу друге ім'я. Цього імені не торкаються обмеження стандарту ISO 9660, що дозволяє вказувати довільні імена файлів системи UNIX на CD - ROM.
Наступні три поля використовуються разом, щоб обійти обмеження стандарту ISO 9660 на глибину вкладеності каталогів. З їх допомогою можна вказати, куди в дереві ієрархії має бути переміщений той або інший каталог.
Нарешті, поле TF містить три тимчасові штампи, що включаються в кожного i-вузол системи UNIX, а саме: час створення файлу, останньої зміни файлу і останнього доступу до файлу. Всі разом ці розширення дозволяють скопіювати файлову систему UNIX на CD - ROM, а потім коректно відновити її на іншій машині.
Розширення Joliet
Співтовариство UNIX було не єдиною групою, якій було потрібно розширеня стандарту ISO 9660. Корпорація Microsoft також дійшла висновку, що стандарт ISO 9660 містить надто багато обмежень (хоча більшість обмежень були викликані в першу чергу вимогою сумісності з файловою системою MS - DOS фірми Microsoft). Тому корпорація Microsoft розробила деякі розширення, названі Joliet. Вони повинні були дозволити копіювати на CD - ROM - диск і відновлювати з нього файлову систему Windows подібно до того, як розширення Рок-Ридж дозволяли працювати з файловою системою UNIX. Теоретично усі програми, що працюють в операційній системі Windows і використовуючи CD, - ROM, включаючи програми запису на CD - R, підтримують розширення Joliet.
Основними розширеннями, що містяться в Joliet, є:
Довгі імена файлів.
Набір символів Unicode.
Глибина вкладеності каталогів, що перевищує вісім рівнів.
Імена каталогів з розширеннями.
Перше розширення дозволяє використовувати імена файлів завдовжки до 64 символів. Друге розширення дозволяє використовувати для імен файлів символи Unicode. Це розширення важливе для програмного забезпечення, призначеного для поширення в країнах, в яких не використовується латинський алфавіт, таких як Японія, Ізраїль або Греція. Оскільки символи Unicode займають два байти, максимальне ім'я файлу в розширенні Joliet займає 128 байт.
Як і Рок-Ридж, розширення Joliet усуває обмеження на глибину вкладеності каталогів. Каталоги можуть вкладатися один в одного на будь-яку необхідну глибину. Нарешті, у імен каталогів можуть бути розширення. Неясно, чому було включено таке розширення стандарту, оскільки каталоги у файловій системі Windows практично ніколи не використовують розширень, але, можливо, колись їх буде потрібно.
Файлова система СР/М
Перші персональні комп'ютери (що називалися тоді міні-комп'ютерами) з'явилися на початку 80-х років. У одній популярній моделі персонального комп’ютера використовувався 8-розрядний центральний процесор Intel 8080. У цього комп’ютера були 4 Кбайт ОЗУ і один 8-дюймовий накопичувач для змінних гнучких дисків місткістю 180 Кбайт. У пізніших версіях цієї машини застосовувався дещо потужніший (хоча все одно 8-розрядний) процесор Zilog Z80. У нього були до 64 Кбайт ОЗУ і величезний 720-кілобайтний гнучкий диск як основний пристрій зберігання даних. Незважаючи на невисоку швидкодію і невелику кількість пам'яті, майже на усіх цих машинах працювала напрочуд потужна дискова операційна система СР/М (Control Program for Microcomputers - програма, що управляє, для мікрокомп'ютерів)[130]. Ця операційна система була домінуючою у свою епоху, так само як MS - DOS і пізніше Windows стали лідерами у світі IBM PC. Через двадцять років вона зникла, не залишивши сліду (якщо не рахувати нечисленної групи твердокамінних прибічників), і це наводить на думку про те, що системи, що лідирують сьогодні у світі (наприклад, Windows), можуть виявитися нікому невідомими на той час, коли сьогоднішні карапузи стануть студентами коледжів.
Варто поглянути на операційну систему СР/М з кількох причин. По-перше, історично це була дуже важлива система, що стала прямим попередником системи MS - DOS. По-друге, розробники сьогоднішніх операційних систем і систем майбутнього, що вважають, що комп'ютеру потрібно 32 Мбайт пам'яті, тільки щоб завантажити в неї операційну систему, можуть повчитися простоті системи, якої цілком вистачало 16 Кбайт ОЗУ. По-третє, в найближчі десятиліття широке застосування отримають вбудовані системи. У зв'язку з обмеженнями в ціні, розмірах, вазі і споживаній потужності операційні системи, використовувані, наприклад, в годиннику, відео- і фотокамерах, радіоприймачах і стільникових телефонах, обов'язково мають бути компактними, подібно операційній системі СР/М. Звичайно, у цих систем не буде 8-дюймових гнучких дисків, але вони цілком можуть користуватися електронними дисками у ФЛэШ-ОЗУ, на яких нескладно організувати файлову систему, подібну СР/М.
Розподіл пам'яті в системі СР/М свідчень на малий. 6.27. Вгорі оперативної пам'яті (у ОЗУ) розташовується базова система введення-виведення BIOS, що містить базову бібліотеку - 17 викликів введення-виводу, використовуваних системою СР/М (у цьому розділі мі розглянемо СР/М 2.2, що була стандартною версією, коли СР/М була на вершині популярності). Ці системні виклики призначені для читання і запису з гнучкого диска, введення з клавіатури і виводу на екран.
Мал. 6.27. Розподіл пам'яті в системі СР/М
Відразу під BIOS розташовується сама операційна система. Для версії СР/М 2.2 її розмір складає 3584 байт. Неймовірно, але факт: уся операційна система займала менше 4 Кбайт. Під операційною системою розміщується оболонка (обробник командних рядків), що з'їдає ще 2 Кбайт. Інша пам'ять використовується для програм користувача, окрім нижніх 256 байт, зарезервованих для векторів апаратних переривань, деяких змінних і буфера для поточної командної стрічки, в якому до неї можуть дістати доступ програми користувача.
Причина, по якій система BIOS відокремлена від самої операційної системи СР/М (хоча обидві системи розташовуються в ОЗУ), полягає в переносності. Операційна система СР/М взаємодіє з апаратурою тільки за допомогою звернень до BIOS. Для перенесення системи СР/М на нову машину треба усього лише перенести туди BIOS. Коли це зроблено, сама СР/М може бути установлена без змін.
У файловій системі СР/М всього один каталог, що містить записи фіксованого розміру (32 байт). Розмір каталогу, фіксований для цієї реалізації, може відрізнятися в інших реалізаціях системи СР/М. В цьому каталозі перераховуються усі файли системи. Після завантаження система прочитує каталог і розраховує бітовий масив зайнятих і вільних блоків. Цей бітовий масив, розмір якого для 180-кілобайтного диска складає всього 23 байти, постійно зберігається в оперативній пам'яті. Після завершення роботи операційної системи він не зберігається на диску. Завдяки такому підходу зникає необхідність в перевірці несуперечності файлової системи на диску (на зразок тієї, що виконує програма fsck в UNIX) і зберігається на диску один блок (у процентному відношенні це еквівалентно збереженню 90 Мбайт на сучасному 16-гігабайтному диску).
Коли користувач набирає команду, оболонка спочатку копіює її в буфер в нижні 256 байт пам'яті. Потім вона шукає програму, що викликається, і завантажує її в пам'ять за адресою 256 (над вектором переривань), після чого передає керування за цією адресою. Програма починає роботу. Вона виявляє свої параметри в буфері командного рядка. Програмі дозволяється використовувати пам'ять, займану оболонкою, якщо їй потрібно багато пам'яті. Закінчивши роботу, програма виконує системний виклик СР/М, повідомляючи операційну систему, що слід перезавантажити оболонку (якщо займана нею пам'ять використовувалася програмою) і запустити її. Двома словами, ось, власне, і уся розповідь про операційну систему СР/М.
Окрім завантаження програм, система СР/М надає програмам користувача 38 системних викликів, що переважно відносяться до файлової служби. Найбільш важливими з них є системні виклики читання з файлу і запису у файл. Перш ніж файл може бути прочитаний, його слід відкрити. Коли СР/М отримує системний виклик open, вона повинна прочитати свою єдину ката-балку і знайти в ній необхідний файл. Для економії дорогоцінної пам'яті цю ката-балку не зберігається в ОЗУ постійно. Коли СР/М виявляє описувач файлу, вона відразу ж отримує номери дискових блоків файлу, що містяться прямо в нім, а також усі інші атрибути. Формат каталогового запису показаний на мал. 6.28.
Мал. 6.28. Формат каталогового запису в системі СР/М
Значення полів на мал. 6.28 наступне. Поле User code (код користувача) вказує власника файлу. Хоча в кожен конкретний момент часу в системі СР/М може знаходитися лише один користувач, системою підтримується почергова робота декількох користувачів. При пошуку імені файлу файлова система перевіряє тільки записи, що належать поточному зареєстрованому користувачеві. В результаті кожен користувач отримує свій віртуальний каталог без необхідності управляти декількома каталогами.
У наступних двох полях містяться ім'я і розширення файлу. Розмір базового імені може бути до восьми символів. Також може використовуватися (необов’язково) розширення файлу завдовжки до трьох символів. Формат імені файлу з 8 + 3 сім-волів верхнього регістра був пізніше запозичений в MS - DOS.
Поле Block count (лічильник блоків) містить розмір файлу, виміряний в одиницях по 128 байт (оскільки вводу-виводу виконується в 128-байтових1 фізичних секторах). Останній кілобайтний блок файлу може бути заповнений не до кінця, тому у системи немає способу визначити точний розмір файлу. Кінець файлу може бути при необхідності вказаний користувачам за допомогою спеціального маркера. Останні 16 полів містять самі номери дискових блоків, що займає файл. Розмір кожного блоку 1 Кбайт, тому максимальний розмір файлу дорівнює 16 Кбайт. Зверніть увагу, що фізичне вводу-виводу виконується в 128-байтових секторах і розмір файлу зберігається в 128-байтових секторах, але файлам виділяються блоки розміром по 1 Кбайт (відразу по 8 секторів), щоб не збільшувати розмір каталогового запису.
Проте розробник системи СР/М розумів, що деякі файли, навіть на 180-кілобайтному гнучкому диску, можуть перевершити розмір 16 Кбайт, тому для обходу 16-кілобайтного обмеження був придуманий наступний трюк. Для файлу розміром від 16 до 32 Кбайт використовується не один каталоговий запис, а два. У першому записі містяться номери перших 16 блоків диска; у другому записі - наступні 16 блоків. При перевищенні файлом 32 Кбайт потрібно третій каталоговий запис і т. д. Порядковий номер каталогового запису зберігається в полі Extent (екстент), завдяки якому операційна система може визначити, які 16 Кбайт знаходяться на початку файлу, які йдуть услід і т. д.
Після того, як системний виклик open виконаний, адреси усіх дискових блоків стають відомі, тому реалізація системного виклику read не представляє складності. Системний виклик write також простий. Для цього потрібно усього лише виділення файлу нового вільного блоку з бітового масиву, що зберігається в оперативній пам'яті, і запис блоку. Послідовні блоки файлу не містяться послідовно на диску, оскільки центральний процесор Intel 8080 не устигає обробити переривання і почати читання наступного блоку. Замість цього використовується чергування блоків, що дозволяє прочитувати декілька блоків за один оборот диска.
Система СР/М, очевидно, не є останнім словом в області сучасних файлових систем, але вона відрізняється своєю простотою, швидкістю і може бути реалізована компетентним програмістом менш ніж за тиждень. Для багатьох вбудованих застосувань, можливо, більшого і не вимагається.
Файлова система MS - DOS
У першому наближенні файлова система MS - DOS є збільшена і поліпшена версія СР/М. Вона працює тільки на платформах з центральним процесором Intel, не підтримує багатозадачності і працює лише в реальному режимі IBM PC (спочатку цей режим був єдиним режимом). Оболонка містить більше можливостей, чим в СР/М, системних викликів теж більше в MS - DOS, але основною функцією операційної системи усе також залишається завантаження програм, управління екраном, обробка введення з клавіатури і керування файловою системою. Саме остання функція і цікавитиме нас в цій главі.
Файлова система MS - DOS багато в чому нагадує файлову систему СР/М, включаючи використання імен файлів, що складаються з 8 + 3 символів верхнього регістра. У першій версії системи (MS - DOS 1.0) був навіть всього один каталог, як і в СР/М. Проте, починаючи з MS - DOS 2.0, функціональність файлової системи значно розширилася. Найсерйознішим поліпшенням став перехід на ієрархічну файлову систему, в якій каталоги могли вкладатися один в одного на довільну глибину. Це означало, що кореневий каталог (розмір якого як і раніше був обмежений) міг містити підкаталоги, які, у свою чергу, також могли містити підкаталоги і т. д. до безкінечності. Зв'язки, прийняття в UNIX, не допускалися, тому файлова система була деревом, що починалося в кореневому каталозі.
Різні прикладні програми досить часто починають з того, що створюють в кореневому каталозі підкаталог, в який складають усі свої файли, що дозволяє програмам уникнути конфлікту. Оскільки самі каталоги зберігаються в MS - DOS як файли, немає ніякого обмеження на число каталогів або файлів на диску. Проте на відміну від СР/М, в MS - DOS немає концепції різних користувачів. Відповідно, будь-який користувач, що увійшов до системи, отримує доступ відразу до усіх файлів.
Щоб прочитати файл, програма, що працює в системі MS, - DOS, повинна спочатку зробити системний виклик open, щоб отримати дескриптор файлу. Системному виклику open як один з вхідних аргументів слід вказати шлях до файлу, який може бути як абсолютним, так і відносним (відносно поточного каталогу). Файлова система відкриває каталоги, перераховані в дорозі, один за іншим, поки не виявляє останній каталог, який зчитується в оперативну пам'ять. Потім в прочитаному каталозі шукається описувач файлу який вимагається відкрити.
Хоча каталоги у файловій системі MS - DOS змінного розміру, каталогові записи, що використовуються, як і в СР/М, мають фіксований розмір 32 байт. Формат описувача файлу системи MS - DOS свідчень на малий. 6.29. У нім міститься ім'я файлу, його атрибути, дата і година створення, номер початкового блоку і точний розмір файлу. Імена файлів коротше за 8 + 3 символи вирівнюються по лівому краю полів і доповнюються пропусками, кожне поле окремо. Поле Attributes (атрибути) є новим полемо, що містить біти, що вказують, що для файлу дозволене тільки читання, що файл має заархівувати, що файл є системним або прихованим. Запис у файл, для якого дозволене тільки читання, не дозволяється. Таким чином здійснюється захист файлів від випадкового запису або видалення. Біт archived (архівний) не встановлюється і не перевіряється операційною системою MS - DOS. Він зарезервований в описувачі для архівуючих програм рівня користувача, що скидають цей біт при створенні резервної копії файлу, тоді як програми, що модифікують файл, повинні встановлювати цей біт. Таким чином архівуюча програма може визначити, які файли підлягають архівації. Біт hidden (прихований файл) дозволяє уникнути відображення файлу в переліку файлів каталогу. Основне його призначення полягає в тому, щоб приховати від недосвідчених користувачів файли, призначення яких їм невідоме. Нарешті, біт system (системний) також ховає файли і захищає їх від випадкового видалення командою del. Цей біт встановлений у основних компонентів системи MS - DOS.
