Journalling and ReiserFS
З виходом релізу 2.4 Linux з'явилася можливість використання filesystem з новими властивостями, таких як Reiserfs, XFS, GFS та інших. Ці filesystems ще не досить випробувані і є питання, що саме вони можуть робити, наскільки вони гарні і наскільки виправдано їх використання в промисловій Linux середовищі. Daniel Robbins відповідає на ці питання по ходу пояснення інсталяції цих нових просунутих filesystems під Linux 2.4. У цій, першій статті з циклу, даються пояснення по journalling взагалі і ReiserFS зокрема.
Що слід очікувати від прочитання цього циклу статей.
Це те, що слід мати на увазі. Однак, відкриваючи цикл, я кілька відволікаюся від поставленої "практичної" цілі і відволікаюся на невелике "теоретичне" вступ. Далі будуть охоплені дві теми, дуже важливі для Linux development community - "журнализация" і "технічна" точка зору на проект ReiserFS. Journalling - технологія, яку довго чекали, і прийшов час її практичного використання. На цій технології працюють ReiserFS, XFS, JFS, ext3 і GFS. Важливо точно зрозуміти, що власне робить journalling і чому Linux її потребує. Навіть якщо вам це добре відомо, я сподіваюся, що моє journalling intro Вам буде корисно. Це хороша "риба" для пояснення технології іншим і дещо для практики. Часто процес впровадження нового доводиться починати з "Linux guy / gal", переконуючи інших в необхідності "якісного стрибка".
Введення в journalling: meta-data
Почнемо з банального. Файлові системи існують для того, щоб зберігати, знаходити і маніпулювати даними. Для виконання таких завдань сама файлова система повинна мати внутрішню "керуючу" структуру, яка дозволяє все це робити. Така внутрішня структура ( "the data about the data") називається meta-data. Від організації цих meta-data залежать робочі характеристики файлових систем (і це те, чим файлові системи один від одного відрізняються).
Зазвичай з такими meta-data сам користувач не взаємодіє. Замість цього з ними працює драйвер файлової системи. Linux filesystem driver спеціально розроблений для управління цим лабіринтом метаданих. Однак, для функціонування драйвера є одна важлива вимога; він очікує бачити метадані в розумному, несуперечливому, що не зруйнованому стані. В іншому випадку звернення до файлів стає неможливим.
Введення в journalling: fsck
Поговоримо про fsck. Десь на початку завантаження Linux запускається fsck і починається сканування всіх локальних файлових систем (перераховані в / etc / fstab). Робиться це для того, щоб гарантувати несуперечність meta-data і, в кінцевому рахунку, можливість монтування файлової системи. Таке сканування займає багато часу і, з метою "економії", передбачається наступне. Якщо Linux завершує роботу "коректно", то скидання на диск всіх кешованих даних відбувається "штатно". В такому випадку є гарантія, що filesystem демонтувати "чисто" і готова до чергового монтування. Як правило, fsck обмежується тільки перевіркою "прапора чистого размонтирования" і, якщо проблем немає, робить розумне припущення, що з meta-data все OK.
Однак всі ми знаємо, що відбуваються і аварійні ситуації внаслідок збою в харчуванні або глибокого зависання системи. У таких ситуаціях про "чистому размонтировании" зі скиданням всіх кешованих даних на диск мови не йде. Якщо таке відбувається, черговий запуск fsck виявляє це і робиться розумний висновок, що filesystems, ймовірно, не готова до взаємодії з драйвером. Дуже може бути, що meta-data знаходяться в суперечливому стані.
Щоб ліквідувати можливі наслідки, fsck почне повне сканування і перевірку несуперечності метаданих, по ходу виправляючи багато помилок. У більшості випадків після "сканування з виправленнями" файлова система готова до монтування. Слід зрозуміти, що здатність до монтування ще не означає цілісність самих даних.
Проблеми з fsck
Не можна сказати, що описане - поганий підхід до забезпечення цілісності файлової системи, але рішення не оптимально. Чи не оптимальність результат того, що fsck повинен просканувати всі метадані файлової системи для висновку про їх несуперечності. Виконання повної перевірки всіх метаданих завдання сама по собі трудомістка. До цього слід додати, що зі збільшенням розміру файлової системи витрати на повне сканування ростуть прогресивно (на персональній машині це може зайняти кілька хвилин, на сервері півгодини і більше). І ще, стандартну поведінку fsck передбачає періодично перевірки після деякого числа "чистих Розмонтування", що не може вважатися прийнятним для mission-critical datacenter, коли "час - гроші". На щастя, є краще рішення.
Журнальованою файлові системи знімають проблему fsck через додаткову data structure, звану журналом. Такий журнал - on-disk structure. Перш, ніж драйвер файлової системи зробить будь-яка зміна в meta-data, робиться запис в журнал з описом майбутніх дій. Тільки після цього відбувається зміна самих метаданих. Таким чином, журнальована файлова система обслуговує реєстраційний файл останніх модифікацій метаданих. Витрати на ведення такого журналу незрівнянно нижче, ніж сканування всієї файлової системи на предмет несуперечливості метаданих.
Уявіть собі ланцюжок - зберігаються дані (stuff), "дані про ці дані" (the data about the stuff) і журнал з meta-meta-data (the data about the data about the stuff).
Journalling в дії.
Тепер перейдемо до ReiserFS, першою з декількох журнальованою файлових систем, які планується досліджувати. ReiserFS 3.6.x (версія для Linux 2.4) розроблена Hans Reiser і його командою Namesys. Hans і його команда проповідують філософію, що найкраща файлова система та, яка формує єдину загальнодоступну середу, або namespace. В такому середовищі додатки можуть взаємодіяти більш гнучко, ефективно і потужно. Для досягнення цього, файлова система повинна виконувати частину роботи, традиційно виконувалася додатками. При такому підході користувачі часто можуть продовжувати пряме використання файлової системи замість формування рівнів спеціального призначення, типу баз даних і т.п.
Робота з маленькими файлами.
Як йдуть справи з розміщенням в файлової системі великого числа маленьких порцій інформації? У Namesys вирішили, по крайней мере, для початку, зосередиться на одному з аспектів роботи файлової системи - роботі з маленькими файлами. Строго кажучи, файлові системи на зразок ext2 і ufs в цій області ведуть себе неефективно, часто змушуючи розробників проектувати бази даних або використовувати інші "фокуси" для отримання задовільною продуктивності. Такий підхід призводить до "винаходу безлічі велосипедів" і породжує величезну кількість несумісних API вузькоспеціального призначення.
Розберемося, а за рахунок чого ext2 заохочує цей вид "велосипедного" програмування. Ext2 хороша для зберігання досить великого числа файлів розміром більше двадцяти кілобайт кожен, але зовсім не ідеальна для зберігання 2,000 50-байтових файлів. Мало того, що помітно знижується продуктивність, але і саме зберігання маленьких файлів на ext2 призводить до неефективного використання дискового простору, так як ext2 асигнує під кожен файл ціле число 1-2-4 KB блоків (розмір блоку встановлюється при формуванні файлової системи).
Звичайна життєва мудрість підказує нам відмовитися від зберігання багатьох сміховинно маленьких файлів безпосередньо на файлову систему. Замість цього виникає ідея зберігання інформації в деякій базі даних, яка працює над filesystem. У відповідь на це Hans Reiser сказав би, що всякий раз, коли формується рівень над filesystem, це свідчить лише про те, що файлова система не відповідає нашим потребам. Якби вона задовольняла, від цього можна було б відмовитися. Отже, добре спроектована файлова система економить час на розробку і усуває ні з чим більш несумісний код.
Але це все теорія. А як на практиці ReiserFS працює з великим числом маленьких файлів? Дивно, але дуже добре. Фактично, ReiserFS для роботи з файлами розміром менше одного K виграє в швидкості у ext2 о восьмій - п'ятнадцять разів! Взагалі, ReiserFS перевершує за швидкодією ext2 в майже кожній області, але дійсно сяє, коли порівнюється обробка маленьких файлів.
технологія ReiserFS
За рахунок чого ReiserFS ефективно працює з маленькими файлами? ReiserFS використовує спеціально оптимізовані b * balanced tree (одне на filesystem) для організації всіх даних файлової системи. Одне це дає велике збільшення продуктивності, а також знімає ряд штучних обмежень на розміщення файлової системи. Наприклад, стає можливим мати каталог, що містить 100,000 інших підкаталогів. Ще одна вигода від використання b * tree в тому, що ReiserFS, подібно до більшості інших filesystems нового покоління, динамічно асигнує inodes замість їх статичного набору, що утворюється при створенні "традиційної" файлової системи. Це дає велику гнучкість і оптимальність у формуванні простору зберігання.
ReiserFS також має ряд features, націлених спеціально для поліпшення роботи з маленькими файлами. ReiserFS не пов'язана обмеженням в асигнування пам'яті для файлу в цілому числі 1-2-4 KB блоків. За необхідності для файлу може асигнуватися точний розмір. ReiserFS також включає деякі види спеціальної оптимізації файлових "хвостів" для зберігання кінцевих частин файлів, менших, ніж блок filesystem. Для збільшення швидкості, ReiserFS здатний зберігати вміст файлів безпосередньо всередині b * tree, а не у вигляді покажчика на дисковий блок (в ext2 є поняття fastlink, коли вміст "м'якої" посилання до 60 байт зберігається в inode).
Тим самим досягається дві речі. Перше, сильно збільшується продуктивність, так як data і stat_data (inode) інформація може зберігатися поруч і зчитуватися однієї дискової операцією IO. Друге, ReiserFS здатний упакувати хвости, економлячи дисковий простір. Фактично, при вирішенні ReiserFS виконувати упаковку хвостів (значення за замовчуванням) заощаджуватиметься приблизно шість відсотків дискового простору (в порівнянні з ext2).
Слід мати на увазі, що упаковка хвостів вимагає додаткової роботи, так як при зміні розмірів файлів необхідна "перепакування". З цієї причини в ReiserFS упаковка хвоста може відключатися, дозволяючи адміністратору вибрати між швидкістю і ефективністю використання дискового простору.
ReiserFS - чудова filesystem. У наступній статті буде описаний процес інсталяції ReiserFS під Linux 2.4. Буде описана процедура оптимальної настройки під вимоги додатків, опції ядра і інше.
About the author
Residing in Albuquerque, New Mexico, Daniel Robbins is the President / CEO of Gentoo Technologies, Inc. and the creator of Gentoo Linux. an advanced Linux for the PC, and the Portage system, a next-generation ports system for Linux. He has also served as a contributing author for the Macmillan books Caldera OpenLinux Unleashed. SuSE Linux Unleashed. and Samba Unleashed. Daniel has been involved with computers in some fashion since the second grade, when he was first exposed to the Logo programming language as well as a potentially dangerous dose of Pac Man. This probably explains why he has since served as a Lead Graphic Artist at SONY Electronic Publishing / Psygnosis. Daniel enjoys spending time with his wife, Mary, and his new baby daughter, Hadassah. You can contact Daniel at [email protected].