12.4 Надійність файлової системи.
Життя сповнене неприємних несподіванок, а руйнування файлової системи найчастіше небезпечніше, ніж руйнація комп'ютера. Тому необхідно вживати спеціальних заходів для збереження структури файлової системи на диску. Крім очевидних рішень, наприклад, своєчасне дублювання інформації (backup), файлові системи сучасних ОС містять спеціальні засоби підтримки власної сумісності.
12.4.1 Цілісність файлової системи.
У сучасних ОС передбачені заходи, які дозволяють звести до мінімуму збитки від псування файлової системи і потім відновити її цілісність.
Вочевидь, що з правильного функціонування файлової системи, значимість окремих даних нерівноцінна. Спотворення вмісту файлів користувача не призводить до серйозних (з точки зору цілісності файлової системи) наслідків, тоді як невідповідності у файлах, що містять керуючу інформацію (директорії, індексні вузли, суперблок і т.п.), можуть бути катастрофічними. Тому має бути ретельно продуманий порядок здійснення операцій із структурами даних файлової системи.
Іншим засобом підтримки цілісності є спосіб реалізації файлової операції у вигляді транзакції, приблизно як це робиться в СУБД. Послідовність дій з об'єктами під час файлової операції протоколюється, і, якщо сталася зупинка системи, то, маючи протокол, можна здійснити відкат системи назад у вихідний цілісний стан, в якому вона перебувала до початку операції. Такі журналування реалізовано в NTFS.
Якщо ж порушення все ж таки відбулося, то для усунення проблеми несумісності можна вдатися доутилітів(fsck, chkdsk, scandisk та ін), які перевіряють цілісність файлової системи.
12.4.2 Управлінняпоганими блоками.
Під поганими блоками зазвичай розуміють блоки диска, для яких обчислена контрольна сума даних, що зчитуються, не збігається зі збереженою контрольною сумою. Часто з'являються у процесі експлуатації. Іноді вони є при постачанні разом із списком, т.к. дуже важко для постачальників зробити диск повністю вільним від дефектів. Два рішення проблеми поганих блоків - одне лише на рівні апаратури інше лише на рівні ядра ОС.
Перший спосіб – зберігати список поганих блоків у контролері диска. Коли контролер ініціалізується, він читає погані блоки та заміщає дефектний блок резервним, позначаючи відображення у списку поганих блоків. Усі реальні запити будуть надходити до резервного блоку. Слід мати на увазі, що при цьому один із найпоширеніших механізмів обробки запитів до блоків диска працюватиме неефективно. Справа в тому, що існує стратегія черговості обробки запитів до диска, яка диктує напрямок руху зчитує головки диска до потрібного циліндра. Зазвичай резервні блоки розміщуються на зовнішніх циліндрах. Якщо поганий блок розташований на внутрішньому циліндрі, і контролер здійснює підстановку прозорим чином, то рух головки, що здається, буде здійснюватися до внутрішнього циліндра, а фактичне до зовнішнього. Це є порушенням стратегії і, отже, мінусом цієї схеми.
Рішення лише на рівні ОС то, можливо наступним. По-перше, необхідно ретельно сконструювати файл, що містить погані блоки. Тоді вони вилучаються із списку вільних блоків. Потім потрібно зробити так, щоб до цього файлу не було звернень. Якщо це можливо, то проблему вирішено.