Опубліковано друге інтерв'ю з Едуардом Шишкіним, розробником файлової системи Reiser4.
Для початку нагадай, будь ласка, читачам, де й ким ти працюєш.
Я працюю на посаді Principal Storage Architect у компанії Huawei Technologies, German Research Center. У відділі віртуалізації займаюсь різними аспектами зберігання даних. Моя діяльність не пов'язана із конкретною операційною системою.
Чи комітиш ти зараз в основну гілку ядра?
Дуже рідко, і якщо це вимагає мій роботодавець. Останній раз три роки тому я посилав патчі, що дозволяють підвищити пропускну здатність для сховищ, розшарених на хостах за протоколом 9p (інша назва цієї справи — VirtFS). Тут треба зробити одне важливе зауваження: хоч я і давно працюю поряд з Лінукс, його фанатом я ніколи не з'являвся, тобто «дихаю рівно», як і до всього іншого. Зокрема, якщо я помітив якусь ваду, то можу вказати на неї максимум один раз. А так, щоб потім за кимось ходити та вмовляти — такого не буде.
Пам'ятається, минулого разу, десять років тому, ти досить критично відгукувався про стиль розробки ядра. Чи змінилося з твоєї (або, можливо, корпоративної) точки зору щось, спільнота стала більш чуйною чи ні? Якщо ні, хто, на твою думку, у цьому винен?
Я так і не побачив будь-яких зрушень на краще. Основна проблема співтовариства — це підміна науки політтехнологіями, персональними відносинами, думкою більшості, популізмом, порадами «внутрішніх голосів», гнилими компромісами, чим завгодно крім науки. Computer science, як не крути, насамперед точна наука. І якщо хтось починає проголошувати для 2×2 своє значення, відмінне від 4, під прапором «Linux way», або під якимось іншим, то крім шкоди це навряд чи принесе.
Усі біди передусім від некомпетентності та неосвіченості тих, хто приймає рішення. Якщо керівник некомпетентний, він здатний прийняти об'єктивне адекватне рішення. Якщо він до того ж безкультурний, він не здатний знайти компетентного фахівця, який дасть йому правильну пораду. З великою ймовірністю вибір паде на шахрая, який говорить «на вигляд правильні речі». Навколо некомпетентних лідерів-одинаків завжди складається корумповане оточення. Причому історія не знає винятків щодо цього, і співтовариство — найяскравіше підтвердження цього.
Як ти оцінюєш прогрес у розробці Btrfs? Ця ФС позбавилася дитячих хвороб? Як ти її для себе позиціонуєш — як ФС «для дому» чи корпоративного застосування теж?
Не позбулася. Все те, про що я згадував 11 років тому, є актуальним і досі. Одна з проблем Btrfs, яка робить останню непридатною для серйозних потреб, — проблема вільного місця. Я вже не кажу про те, що користувачеві пропонується бігти в магазин за новим диском у ситуаціях, коли будь-яка інша ФС показала б ще безліч вільного місця на розділі. Неможливість завершити операцію над логічним томом через брак вільного місця — це теж не найстрашніше. Найгірше те, що непривілейований користувач майже завжди може за досить короткий час в обхід будь-яких дискових квот позбавити вільного місця.
Виглядає так (перевірено для ядра Linux 5.12). На свіжеінстальованій системі запускається скрипт, який у циклі створює в домашній директорії файли з певними іменами, записує в них дані щодо певних зсувів і потім видаляє ці файли. За хвилину роботи цього скрипта нічого незвичайного не відбувається. Через п'ять хвилин порція місця на розділі злегка збільшується. Через дві-три години вона сягає 50% (при початковому значенні 15%). А після п'яти-шостої години роботи скрипт валиться з помилкою «немає вільного місця на розділі». Після цього ви вже не в змозі записати на ваш розділ навіть 4К файл.
Відбувається цікава ситуація: ви нічого на розділ у результаті не записали, а все вільне місце (порядку 85%) кудись зникло. Аналіз розділу, підданого такій атаці, покаже безліч вузлів дерева, що містять лише один айтем (об'єкт, з ключем), розміром кілька байт. Тобто, контент, який раніше займав 15% дискового простору, виявився рівномірно «розмазаним» на весь розділ так, що новий файл записати вже нікуди, бо його ключ найбільший за існуючі, а вільні блоки на розділі закінчилися.
Причому це все відбувається вже на базовій конфігурації Btrfs (без будь-яких снапшотів, сабвольюмів тощо), і не має значення те, як ви вирішили зберігати тіла файлів у тій ФС (як «фрагменти» в дереві, або як екстенти неформатованих блоків) — кінцевий результат буде той самий.
Піддати такій атаці решта файлових систем з апстріму вам не вдасться (що б вам там не говорили). Причину проблеми я вже давно пояснив: це повне збочення в Btrfs поняття B-дерева, що уможливлює його спонтанне чи навмисне виродження. Зокрема, при деяких навантаженнях ваша ФС в процесі експлуатації безперервно «розвалюватиметься» і сама, без сторонньої допомоги. Зрозуміло, що всілякі фонові процеси, що «підтискають», врятують справу тільки на індивідуальних десктопах.
На колективних серверах зловмисник завжди буде в змозі їх «випередити». Системний адміністратор навіть не зможе визначити, хто саме з нього знущався. Найшвидше виправити цю проблему в Btrfs можна лише відновивши структуру регулярного B-дерева, тобто. заново перепроектувавши дисковий формат і переписавши суттєву частину коду Btrfs. Це займе 8-10 років разом з налагодженням за умови, що розробники чітко дотримувалися оригінальних статей за відповідними алгоритмами та структурами даних, а не грали в «зіпсований телефон», як це прийнято (і заохочується) в «Linux way».
Сюди ще треба додати час, необхідний розробникам для того, щоб зрозуміти все це. Ось тут уже складніше. Принаймні 10 років на розуміння їм не вистачило. Ну, а до цього можете не сподіватися на диво. Воно не відбудеться у вигляді опції монтування «про яку ми з вами не знали», або у вигляді патчу, який приготувати «всього справ». Для кожного такого поспішного «виправлення» я представлю новий сценарій виродження. B-дерева — це одна з моїх улюблених тем, і маю сказати, що вільності у поводженні з собою ці структури не терплять!
Як я собі позиціоную Btrfs? Як щось, що називатися файловою системою категорично не може, не кажучи вже про використання. Бо за визначенням ФС це підсистема ОС, відповідальна за ефективне управління ресурсом «дисковий простір», чого у випадку з Btrfs ми не спостерігаємо. Ну, уявіть, що ви прийшли в магазин купити годинник, щоб не спізнюватися на роботу, а там замість годинника вам впарили електрогриль з таймером на 30 хвилин максимум. Так ось - з Btrfs ситуація ще гірша.
Переглядаючи листи розсилок, я часто стикаюся із твердженням, що ефективно керувати дисковим простором вже не актуально через дешевизну накопичувачів. Це цілковита маячня. Без ефективного менеджера дискового простору ОС стане вразливою та непридатною для використання. Незалежно від того, які диски стоять на вашій машині.
Хотілося б попросити прокоментувати припинення підтримки Btrfs у RHEL.
Тут особливо нема чого коментувати, все дуже ясно. Вона ж мала «technology preview». Ось і не пройшла це саме «preview». Не висіти ж вічно цьому ярлику! А запустити неповноцінний by-design продукт з повною підтримкою вони не можуть. RHEL - це ентерпрайз, тобто прописані товарно-грошові відносини. Red Hat не може знущатися з користувачів, як це відбувається в листі розсилки Btrfs. Просто уявіть ситуацію: клієнт, який заплатив свої кревні за диск і ще вам за підтримку, хоче зрозуміти, куди подівся дисковий простір, після того, як він нічого не записав. Що ви йому на це відповісте?
Далі. До клієнтів Red Hat входять відомі великі банки, біржі. Уявіть, що буде, якщо вони піддадуться DoS-атакам, заснованим на згаданій вразливості Btrfs. Як ви вважаєте, хто за це відповість? Тим, хто зібрався тицьнути пальцем у рядок ліцензії GPL, де написано, що автор ні за що не відповідає, одразу скажу: «Сховайте її подалі!» Відповість Red Hat, причому так, що мало не здається! Але я знаю, що Red Hat такого роду проблеми не загрожують, враховуючи їх особливо сильну команду QA-інженерів, з якими мені довелося щільно попрацювати свого часу.
Чому деякі компанії продовжують підтримувати Btrfs у своїх ентерпрайз-продуктах?
Зауважте, що приставка «ентерпрайз» у назві продукту мало про що говорить. Ентерпрайз - це міра відповідальності, закладена в договірні відносини з клієнтом. Я знаю лише один ентерпрайз, заснований на GNU/Linux – це RHEL. Все інше, на мій погляд, лише видається за ентерпрайз, але таким не є. І, нарешті, якщо на щось є попит, то завжди буде й пропозиція (у нашому випадку це згадана підтримка). Попит буває абсолютно на все, в т.ч. та на непридатний для використання софт. Як він формується такий попит, і хто його підживлює це вже інша тема.
Отже, я б не став робити якихось висновків після того, як Facebook з чуток розгорнув Btrfs на своїх серверах. Більше того, адреси тих серверів я б порекомендував ретельно зберігати в таємниці з вищезгаданих причин.
Чому останнім часом багато зусиль докладено до вилизування коду XFS? Адже спочатку це стороння ФС, та й ext4 давно стабільна і має спадкоємність від попередніх таких же стабільних версій. Який інтерес у Red Hat'а до XFS? Чи є сенс активно розробляти дві схожі за призначенням ФС ext4 і XFS?
Вже не пам'ятаю, що це мотивувалося. Цілком можливо, що ініціатива йшла від клієнтів Red Hat. Я пам'ятаю, що проводилися дослідження такого роду: на деяких файлових системах з апстріму створювалася гігантська кількість об'єктів на хай-енд накопичувачах нового покоління. За результатами XFS повелася краще ext4. Ось її і стали просувати як найперспективнішу. У будь-якому разі, я не шукав би тут чогось сенсаційного.
На мене так змінили шило на мило. Розробляти ext4 і XFS немає сенсу. Як паралельно, і будь-яку з них на вибір. Із цього нічого хорошого не вийде. Хоча в природі часто зустрічаються ситуації, коли потенцій для зростання багато, а обсягу куди рости немає. В цьому випадку виникають різні химерно-потворні новоутворення, на які всі показують пальцем («О, дивись, чого тільки в цьому житті не побачиш!»).
Чи вважаєш ти питання про layer violation вичерпаним (негативним) з появою функцій шифрування в ext4, F2FS (не кажучи вже про RAID в Btrfs)?
Взагалі, запровадження будь-яких рівнів та ухвалення рішення про їх непорушення — це зазвичай питання політики, і я не беруся тут щось коментувати. Об'єктивні аспекти порушення рівнів мало кому цікаві, але ми можемо розглянути деякі з них на прикладі порушення «зверху», а саме, реалізацію у ФС функціональності, що вже є на block layer. Таке «порушення» виправдане лише за рідкісним винятком. Для кожного такого випадку ви спочатку повинні довести дві речі: що це дійсно потрібно, і що дизайну системи при цьому не буде завдано шкоди.
Скажімо, дзеркалювання, яке традиційно було заняттям для block layer, має сенс реалізувати на рівні файлової системи. З різних причин. Наприклад, на дискових накопичувачах має місце «тиха» псування даних (bit rot). Це коли пристрій справно працює, але дані блоку несподівано ушкоджуються під впливом жорсткого гамма-кванту, випущеного далеким квазаром і т.п. Найгірше, якщо цим блоком виявився системний блок ФС (суперблок, bitmap-блок, вузол дерева-сховища і т.д), бо це неодмінно призведе до kernel panic.
Зауважте, що дзеркала, які пропонують block layer (т.зв. RAID 1) від цієї проблеми не врятують. Ну, справді: хтось же має перевіряти контрольні суми та зчитувати репліку у разі невдачі? Крім того, є сенс дзеркалірувати не тупо все поспіль, а тільки метадані. Деякі важливі дані (наприклад, файли критичних додатків, що виконуються) можна зберігати на правах мета-даних. У цьому випадку вони отримують такі ж гарантії безпеки. Захист інших даних має сенс доручити іншим підсистемам (можливо, навіть додаткам користувача) — ми надали для цього всі необхідні умови.
Такі «економні» дзеркала цілком мають право на існування та ефективно їх організувати можна лише на рівні файлової системи. В іншому ж layering violation — це захаращення підсистеми дубльованим кодом заради якихось мікроскопічних вигод. Яскравий приклад — це реалізація RAID-5 засобами ФС. Такі рішення (власні RAID/LVM у файловій системі) вбиває останню в архітектурному плані. Тут ще слід зазначити, що layering violation «поставлено на потік» різного роду рекламними шахраями. За відсутністю будь-яких ідей, у підсистеми додається функціональність давно вже реалізована на сусідніх рівнях, це видається за нову надзвичайно корисну фічу і активно проштовхується.
Reiser4 ж звинуватили у порушенні рівнів «знизу». Виходячи з того, що файлова система не монолітна, як усі інші, а модульна, було зроблено нічим не обґрунтоване припущення, що вона займається тим, чим має займатися рівень вище (VFS).
Чи можна говорити про смерть ReiserFS v3.6 і, наприклад, JFS? Останнім часом їм у ядрі майже не приділяється уваги. Вони морально застаріли?
Тут слід визначити, що означає смерть програмного продукту. З одного боку, вони з успіхом використовуються (їх для цього й створювали, зрештою) — отже, живуть. З іншого боку, не скажу за JFS (мало знаю), а ось ReiserFS (v3) дуже важко пристосувати до нових тенденцій (перевірено на практиці). Отже, розробники надалі приділятимуть увагу не їй, а тим, які легко пристосувати. З цього боку виходить, що, на жаль, мертва в архітектурному плані. Поняттям «морально застарілий» я взагалі не маніпулював би. Воно добре застосовується, наприклад, до гардеробу, але ніяк не до програмних продуктів. Є поняття поступатися і перевершувати у чомусь. Цілком точно можу сказати, що ReserFS v3 зараз у всьому поступається Reiser4, але на деяких типах робочого навантаження перевершує всі інші ФС з апстріму.
Чи відомо тобі про створення ФС Tux3 і HAMMER/HAMMER2 (ФС для DragonFly BSD)?
Так, звісно. У Tux3 мене колись зацікавила технологія їх знімків (т.зв. «версійні покажчики»), але Reiser4 ми, швидше за все, підемо іншим шляхом. Я давно думаю про підтримку знімків (snapshots) і ще не визначився про те, як їх реалізувати для простих Reiser4 томів. Справа в тому, що новомодна техніка «лінивих» лічильників посилань, запропонована Охадом Родехом, працює лише для B-дерев. У нас їх нема. Для тих структур даних, які використовуються в Reiesr4, «ліниві» лічильники не визначені — для їх введення необхідно вирішити певні алгоритмічні проблеми, за що ніхто не брався.
За HAMMER: читав статтю від творця. Чи не зацікавило. Знову ж таки, B-дерева. Ця структура даних безнадійно застаріла. Ми відмовилися від неї ще у минулому столітті.
Як ти оцінюєш наростаючу затребуваність у мережевих кластерних ФС на кшталт CephFS/GlusterFS/etc? Чи означає ця затребуваність зрушення пріоритетів розробників у бік мережевих ФС та недостатність уваги до локальних ФС?
Так, таке зрушення пріоритетів відбулося. Розробка локальних ФС стагнувала. На жаль, зробити щось важливе для локальних томів зараз досить складно і далеко не всім під силу. Вкладатися в їхню розробку ніхто не хоче. Це приблизно так само, як попросити комерційну структуру виділити гроші на математичні дослідження – вас без етнузіазму спитають, а як на новій теоремі можна буде заробити. Тепер локальна ФС - це щось, що магічно з'являється "з коробки" і "завжди має працювати", а якщо не працює, то викликає безадресне бурчання на кшталт: "так, що вони там собі думають!".
Звідси брак уваги до локальних ФС, хоча роботи в тій області ще багато. І так, всі повернулися до розподілених сховищ, які будуються на базі локальних ФС, що вже існують. Це зараз дуже модно. Словосполучення «Big Data» у багатьох викликає викид адреналіну, асоціюючись із конференціями, воркшопами, великими зарплатами тощо.
Наскільки розумним у принципі виглядає підхід, у якому мережева ФС реалізується у просторі ядра, а чи не у просторі користувача?
Дуже розумний підхід, який досі ніде не було реалізовано. Взагалі, питання про те, в якому просторі треба реалізовувати мережеву ФС — це «палиця з двома кінцями». Ну, розгляньмо на прикладі. Клієнт записав дані на віддаленій машині. Вони впали у її page cache у вигляді брудних сторінок. Це робота для "тонкого шлюзу" мережевий ФС у просторі ядра. Далі операційна система рано чи пізно попросить записати ті сторінки на диск для їхнього звільнення. Тоді в справу включається IO-forwarding (що відправляє) моду мережевий ФС. Він визначає яку серверну машину (server node) ці сторінки потраплять.
Потім естафету приймає мережевий стек (а він, як ми знаємо, реалізований у просторі ядра). Далі, server node приймає той пакет з даними або метаданими і дає вказівку backend storage - модулю (тобто локальної ФС, яка працює у просторі ядра) записати все це господарство. Отже, ми звели питання до того, де повинні працювати модулі, що «відправляє» і «приймає». Якщо якийсь із тих модулів працюють у просторі користувача, це неминуче призведе до переключення контекстів (через необхідність користування сервісами ядра). Число таких перемикань залежить від деталей реалізації.
Якщо таких перемикань багато, то падатиме пропускна спроможність сховища (продуктивність введення-виведення). Якщо ваш backend storage складений із повільних дисків, то значного падіння ви не помітите. Але якщо у вас диски швидкі (SSD, NVRAM і т.д), то перемикання контекстів вже стає «пляшковим шийкою» і, заощадивши на перемиканні контекстів, можна збільшити продуктивність в рази. Стандартний шлях такої економії полягає у перенесенні модулів у простір ядра. Наприклад, ми з'ясували, що перенесення 9p-сервера з QEMU до ядра на хост-машині призводить до триразового приросту продуктивності VirtFS.
Це, звичайно, не мережна ФС, але суть речей цілком відбиває. Зворотний бік такої оптимізації — це проблеми із переносимістю. Для когось остання може бути критичною. Наприклад, GlusterFS взагалі немає модулів у складі ядра. Завдяки цьому вона зараз працює на багатьох платформах, у тому числі і на NetBSD.
Які концепції локальні ФС могли б запозичити у мережевих та навпаки?
Зараз мережеві ФС, як правило, є надбудовами над локальними ФС, тому я не зовсім розумію, як можна в останніх щось запозичити. Ну, справді, розглянемо компанію із 4 співробітників, у якій кожен займається своєю справою: один розподіляє, інший відправляє, третій отримує, четвертий зберігає. І питання, а що ж компанія може запозичити від її співробітника, який зберігає, звучить якось некоректно (те, що можна було від нього запозичити, вона вже давно має).
А ось локальним ФС є чому повчитися у мережевих. По-перше, вони мають повчитися агрегувати логічні томи високому рівні. Нині т.зв. "передові" локальні ФС агрегують логічні томи виключно за допомогою технології "віртуальних девайсів", запозиченої з LVM (той самий заразний layering violation, який спочатку був реалізований в ZFS). Інакше кажучи, відбувається трансляція віртуальних адрес (номерів блоків) в реальні та назад на низькому рівні (тобто після того, як файлова система видала запит введення-виведення).
Зауважте, що додавання та видалення пристроїв у логічні томи (не дзеркала), скомпановані на block layer, веде до проблем, про які постачальники подібних «фіч» скромно замовчують. Я говорю, про фрагментацію на реальних пристроях, яка може досягати жахливих значень, у той час, як на віртуальному пристрої у вас все чудово. Однак віртуальні пристрої мало кого цікавлять: усім цікаво, що у вас відбувається на реальних пристроях. Але ZFS-подібні ФС (так само як і будь-які ФС у зв'язках з LVM) працюють тільки з віртуальними дисковими пристроями (виділяють віртуальні дискові адреси з-поміж вільних, дефрагментують ці віртуальні пристрої і т.д.). А що відбувається на реальних пристроях, вони навіть поняття не мають!
Тепер уявіть, що на віртуальному пристрої у вас фрагментація дорівнює нулю (тобто у вас там живе лише один гігантський екстент), ви додаєте диск у ваш логічний том, а потім видаляєте інший випадковий диск з вашого логічного тома з наступним перебалансуванням. І так от багато разів. Неважко збагнути, що на віртуальному пристрої у вас як і раніше житиме той самий єдиний екстент, але на реальних пристроях ви нічого хорошого вже не побачите.
Найгірше те, що ви навіть не в змозі виправити цю ситуацію! Єдине, що тут можна зробити – це попросити файлову систему дефрагментувати віртуальний пристрій. Але вона вам скаже, що у вас там все чудово - є тільки екстент, фрагментація дорівнює нулю, а кращого і бути не може! Отже, логічні томи, створені на блочному рівні, не призначені для багаторазового додавання/видалення пристроїв. По-хорошому, потрібно лише один раз скомпанувати логічний том на блочному рівні, віддати його файловій системі, а потім нічого вже більше з ним не робити.
Крім того, зв'язування незалежних підсистем ФС+LVM ніяк не дозволяє враховувати різну природу накопичувачів, з яких агрегуються логічні томи. Дійсно, припустимо, сформували ви логічний том з НЖМД і твердотільних пристроїв. Але тоді перші вимагатимуть дефрагментації, а другі — ні. Для других потрібно видавати discard-запити, а для перших – ні, тощо. Однак у зазначеній зв'язці таку вибірковість виявити досить складно.
Зауважте, що після створення у файловій системі свого власного LVM ситуація значно краще не стає. Більше того, цим ви фактично ставите хрест на перспективі її поліпшити в майбутньому. Це дуже погано. На одній машині можуть жити накопичувачі різного типу. І якщо не файлова система їх розрізнятиме, то хто тоді?
Ще одна проблема підстерігає т.зв. Write-Anywhere файлові системи (сюди ж входить і Reiser4, якщо під час монтування ви задали відповідну транзакційну модель). Такі файлові системи повинні пред'явити безпрецедентні за своєю силою засоби дефрагментації. А низькорівневий менеджер томів тут не допомагає, лише заважає. Справа в тому, що з таким менеджером ваша ФС зберігатиме карту вільних блоків лише одного девайсу — віртуального. Відповідно, дефрагментувати ви зможете лише віртуальний девайс. Це означає, що ваш дефрагментатор довго-довго орати на величезному єдиному просторі віртуальних адрес.
І якщо у вас багато користувачів, які роблять випадкові перезаписи, корисний ефект від такого дефрагментатора зведеться до нуля. Система ваша неминуче почне гальмувати і вам залишиться лише скласти руки перед невтішним діагнозом «broken design». Декілька дефрагментаторів, що працюють на тому самому просторі адрес, тільки заважатимуть один одному. Зовсім інша річ, якщо для кожного реального пристрою ви підтримуєте свою картку вільних блоків. Це дозволить ефективно розпаралелити процес дефрагментації.
Але зробити це можна лише володіючи високорівневим менеджером логічних томів. Локальних ФС з такими менеджерами раніше не існувало (принаймні я про них не знаю). Такі менеджери мали лише мережеві ФС (наприклад GlusterFS). Інший дуже важливий приклад – утиліта перевірки цілісності тома (fsck). Якщо для кожного підтому у вас зберігається своя незалежна карта вільних блоків, процедуру перевірки логічного тома можна ефективно розпаралелити. Інакше висловлюючись, логічні томи з високорівневими менеджерами краще масштабуються.
Крім того, з низькорівневими менеджерами томів ви не зможете організувати повноцінні знімки (snapshots). З LVM і ZFS-подібних ФС ви можете робити тільки локальні знімки, але ніяк не глобальні. Локальні знімки дозволяють моментально відкочувати лише регулярні файлові операції. А операції з логічними томами (додавання/видалення пристроїв) вам ніхто там не відкотить. Давайте розглянемо це з прикладу. У певний момент часу, коли у вас є логічний том із двох пристроїв А і В, що містить 100 файлів, ви робите знімок системи S і потім створюєте ще одну сотню файлів.
Після цього ви додаєте до вашого пристрою С, і нарешті відкочуєте вашу систему до знімку S. Питання: скільки файлів і пристроїв містить ваш логічний том після відкату до S? Файлів, як ви вже здогадалися, буде 100, але пристроїв буде 3 - це ті ж пристрої A, B і C, хоча, на момент створення знімка в системі було всього два пристрої (A і B). Операція додавання пристрою C не відкотилася, і якщо ви зараз видалите пристрій C з комп'ютера, то це закораптить ваші дані, так що перед видаленням вам потрібно буде спочатку провести дорогу операцію видалення пристрою з логічного тома з перебалансування, яка розкидає всі дані з пристрою C на пристрої A і B. А от якби ваша ФС підтримувала глобальні знімки, таке перебалансування не знадобилося б, і після моментального відкату до S ви могли б сміливо видалити пристрій C з комп'ютера.
Отже, глобальні знімки хороші тим, що вони дозволяють уникнути дорогого видалення (додавання) пристрою з логічного тома (в логічний том) з великою кількістю даних (зрозуміло, якщо ви не забули сфотографувати свою систему в потрібний момент). Нагадаю, що створення знімків і відкат файлової системи до них - моментальні операції. Може виникнути питання: а як взагалі таке можливо — миттєво відкотити операцію з логічним томом, яка зайняла три дні? А ось, можливо! За умови, що ваша ФС правильно спроектована. Ідея таких "3D-снапшотів" у мене виникла три роки тому, а торік я запатентував цю методику.
Наступне, чому варто повчитися локальним ФС у мережевих - це зберігати метадані на окремих пристроях точно так, як мережеві ФС зберігають їх на окремих машинах (так звані метадата-сервери). Існують програми, які працюють в основному з метаданими, і ці програми можна значно прискорити, розмістивши метадані на дорогих високопродуктивних накопичувачах. З зв'язкою ФС+LVM виявити таку вибірковість вам не вдасться: LVM не знає, що там на блоці, який ви йому передали (дані там або метадані).
Від реалізації у ФС власного низькорівневого LVM великого виграшу в порівнянні зі зв'язкою ФС+LVM ви не отримаєте, а ось що у вас вийде дуже добре - так це захламити ФС так, що потім неможливо працювати з її кодом. ZFS і Btrfs, що поспішили з віртуальними девайсами, - це наочні приклади того, як layering violation вбиває систему в архітектурному плані. Отже, до чого я все це? Та до того, що не потрібно містити у файловій системі свій власний низькорівневий LVM. Натомість потрібно агрегувати пристрої в логічні томи на високому рівні, як це роблять деякі мережеві ФС з різними машинами (storage nodes). Щоправда, роблять вони це погано через застосування поганих алгоритмів.
Приклади абсолютно жахливих алгоритмів - це транслятор DHT у файловій системі GlusterFS і так званий CRUSH map у файловій системі Ceph. Жоден з тих алгоритмів, що я бачив, не влаштував мене в плані простоти та хорошої масштабованості. А тому довелося згадувати алгебру та винаходити все самому. У 2015 році, експериментуючи з розшаруваннями над хеш-функціями, я вигадав і запатентував те, що мене влаштовує. Зараз можу сказати, що спроба реалізувати все це практично виявилася успішною. Жодних проблем із масштабованістю у новому підході я не бачу.
Так, кожен потім вимагатиме в пам'яті окрему структуру типу суперблоку. Це дуже страшно? Взагалі, я не знаю, хто збирається "кип'ятити океан" і створювати логічні томи із сотень тисяч і більше пристроїв на одній локальній машині. Якщо хтось мені це пояснить, буду дуже вдячний. А поки що для мене це маркетинговий булшит.
Як вплинули зміни у підсистемі блокових пристроїв ядра (наприклад, поява blk-mq) на вимоги до реалізації ФС?
Ніяк не вплинули. Вже не знаю, що там має таке статися на block layer, що довелося б проектувати нову ФС. Інтерфейс взаємодії цих підсистем дуже бідний. З боку драйверів на ФС впливати має лише поява накопичувачів нового типу, до яких підлаштовуватиметься спочатку block layer, а потім вже ФС (для reiser4 це означатиме поява нових плагінів).
Чи поява нових типів носіїв (наприклад, SMR, або повсюдне поширення SSD) принципово нові виклики для проектування ФС?
Так. І це нормальні стимули у розвиток ФС. Виклики можуть бути різні та зовсім несподівані. Наприклад, я чув про накопичувачі, де швидкість операції введення-виведення сильно залежить від розміру шматка даних та його усунення. У Лінуксі, де розмір ФС-блоку не може перевищувати розміру сторінки, такий накопичувач за умовчанням не виявить своїх повних можливостей. Однак, якщо ваша ФС правильно спроектована, тобто шанс багато чого з нього «вичавити».
Скільки людей зараз працює з кодом Reiser4, крім тебе?
Менше, ніж хотілося б, але й гострої нестачі ресурсів я не відчуваю. Темпи розвитку Reiser4 мене більш ніж влаштовують. "Гнати коней" я не збираюся - це не та область. Тут «тише їдеш - далі будеш!» Сучасна ФС - це найскладніша підсистема ядра, неправильні рішення в дизайні якої можуть перекреслити подальшу багаторічну працю людей.
Пропонуючи волонтерам щось реалізувати, я завжди гарантую, що зусилля неодмінно приведуть до коректного результату, який може бути потрібний для серйозних потреб. Як ви розумієте, таких гарантій не може бути багато й одразу. У той же час я терпіти не можу «діячів», які безсоромно піарять «фічі» явно непридатного для використання софту, обманюючи сотні користувачів та розробників, та при цьому сидять та посміхаються на кернел самітах.
Чи виражала якась компанія готовність підтримати розробку Reiser4?
Так, такі пропозиції були, зокрема. та від великого вендора. Але для цього мені треба було переїжджати до іншої країни. На жаль, мені вже давно не 30 років, я не можу зірватися і поїхати ось так от по першому свисту.
Яких функцій не вистачає у Reiser4 зараз?
Не вистачає функції «розтягування» (resize) для простих томів за аналогією до тієї, що є у ReiserFS(v3). Крім того, не завадили б файлові операції із прапором DIRECT_IO. Далі, хотілося б вміти сегрегувати томи на «семантичні підтоми», які не мають фіксованого розміру, і які можна монтувати як самостійні томи. Ці завдання хороші для початківців, які бажають спробувати себе у справжній справі.
І, нарешті, хотілося б мати мережеві логічні томи із простою реалізацією та адмініструванням (сучасні алгоритми вже дозволяють це зробити). А ось чого в Reiser4 точно ніколи не буде - так це RAID-Z, скрабів, кешів вільного простору, 128-бітових змінних та іншої маркетингової нісенітниці, що виникла на тлі дефіциту ідей у розробників деяких ФС.
Чи все те, що може знадобитися, може бути реалізовано плагінами?
Якщо говорити лише в термінах інтерфейсів та плагінів (модулів), які їх реалізують, то не все. Але якщо ввести ще й відносини на цих інтерфейсах, то, крім усього іншого, у вас виникнуть поняття вищих поліморфізмів, якими вже можна обійтися. Уявіть, що ви гіпотетично заморозили об'єктно-орієнтовану систему часу виконання, змінили значення instruction pointer, щоб він вказував на інший плагін, який реалізує той самий інтерфейс X, а потім розморозили систему так, щоб вона продовжила виконання.
Якщо при цьому кінцевий користувач не помітить такої «підміни», то ми говоримо, що система має поліморфізм нульового порядку в інтерфейсі X (або система гетерогенна в інтерфейсі X, що те саме). Якщо тепер у вас не просто набір інтерфейсів, а ще й стосунки на них (граф інтерфейсів), то можна ввести поліморфізми і вищих порядків, які характеризуватимуть гетерогенність системи вже в околиці якого-небудь інтерфейсу. Таку класифікацію я колись давно запровадив, але опублікувати, на жаль, так і не вдалося.
Так ось, за допомогою плагінів і таких вищих поліморфізмів можна описати будь-яку відому фічу, а також «передбачити» ті, які ніколи навіть не згадувалися. Строго довести це мені не вдалося, але й контрприкладу я теж поки що не знаю. Взагалі, це питання нагадав мені «Ерлангенську Програму» Фелікса Клейна. Він свого часу намагався уявити всю геометрію розділом алгебри (конкретно, теорії груп).
Тепер до головного питання - як справи з просуванням Reiser4 в основне ядро? Чи були публікації з архітектури цієї ФС, про які ти говорив у минулому інтерв'ю? Наскільки взагалі з твоєї точки зору це питання актуальне?
Взагалі ми протягом трьох років просили про включення в основну гілку. Останній коментар Рейзера в публічному треді, де зробив запит на включення так і залишився без відповіді. Отже, всі подальші питання — не до нас. Я ж особисто не розумію, навіщо нам «вливатися» до конкретної операційної системи. На Лінуксі світло клином не зійшлося. Отже, є окремий репозиторій, у якому будуть кілька гілок-портів під різні ОС. Кому потрібно - можете клонувати відповідний порт і робити з ним все, що заманеться (в рамках ліцензії, зрозуміло). Ну, а якщо це комусь не потрібне, то це не мої проблеми. На цьому питання про "просування в основне ядро Лінукс" я пропоную вважати вичерпаним.
Публікації з архітектури ФС актуальні, але я поки що знаходив час лише на свої нові результати, які вважаю пріоритетними. Ще річ у тому, що я математик, а в математиці будь-яка публікація — це зведення теорем та їх доказів. Публікувати там щось без доказу - це ознака поганого тону. Якщо ж я сторого доведу або спростую якесь твердження з архітектури ФС, то вийдуть такі нагромадження, через які буде складно продертися. Кому це потрібно? Напевно тому все продовжує залишатися у своєму старому вигляді — вихідний код і коментарі до нього.
Що суттєво нового з'явилося у Reiser4 за останні кілька років?
Матеріалізувалася нарешті довгоочікувана стабільність. Однією з останніх здалася помилка, що призводила до «невіддалених» директорій. Труднощі полягали в тому, що вона виявлялася тільки на тлі колізій хешів імен і при певному розташуванні директорних записів у вузлі дерева. Однак, для продакшену я Reiser4, як і раніше, рекомендувати не можу: для цього треба провести певну роботу при активній взаємодії з адміністраторами продакшн-систем.
Вдалося нарешті реалізувати свій давній задум — різні транзакційні моделі. До цього в Reiser4 працювала тільки одна жесткокодована модель Макдональда-Рейзера. Це створювало проблеми у дизайні. Зокрема, у такій транзакційній моделі неможливі знімки (snapshots) — їх псуватиме компонент атома під назвою «OVERWRITE SET». Зараз Reiser4 підтримує три транзакційні моделі. В одній з них (Write-Anywhere) до атомної компоненти OVERWRITE SET входять лише системні сторінки (образи дискових бітових карт тощо), які «фотографування» не підлягають (проблема курки та яйця).
Тож знімки тепер можна реалізувати у кращому вигляді. В іншій транзакційній моделі всі модифіковані сторінки потрапляють лише в OVERWRITE SET (тобто це по суті чисте журналування). Ця модель для тих, хто скаржився на швидку фрагментацію Reiser4 розділів. Тепер у цій моделі ваш розділ фрагментуватиметься не швидше ніж з ReiserFS (v3). Всі три існуючі моделі за деякими застереженнями гарантують атомарність операцій, проте можуть стати в нагоді також і моделі зі втратою атомарності і зі збереженням лише цілісності розділу. Такі моделі можуть бути корисними для всіляких додатків (бази даних тощо), які вже звалили на себе частину подібних функцій. Додати ці моделі в Reiser4 дуже легко, але я цього не робив, бо мене ніхто не просив, а особисто це мені не потрібно.
З'явилися контрольні суми метаданих і нещодавно я доповнив їх «економічними» дзеркалами» (поки нестабільний матеріал). У разі провалу перевірки контрольної суми якогось блоку Reiser4 негайно зчитує відповідний блок з девайса-репліки. Зауважте, що ZFS та Btrfs так не можуть: не дозволяє дизайн. Там ви повинні запустити спеціальний фоновий скануючий процес під назвою «скраб» і чекати, коли він дістанеться проблемного блоку. Такі заходи програмісти образно називають «милицями».
І, нарешті, з'явилися гетерогенні логічні томи, що пропонують все те, чого ZFS, Btrfs, block layer, а також зв'язки FS+LVM в принципі дати не можуть - це паралельне масштабування, O(1)-аллокатор дискових адрес, прозора міграцією даних між підтомами. Для останньої також є інтерфейс користувача. Тепер найбільш «гарячі» дані ви легко можете перемістити на найбільш високопродуктивний накопичувач вашого тому.
Крім того, є можливість екстрено скидати на такий накопичувач будь-які брудні сторінки, і тим самим значно прискорити програми, що часто викликають fsync(2). Зазначу, що функціональність block layer, звана bcache, не надає такої свободи дій. Нові логічні томи ґрунтуються на моїх алгоритмах (є відповідні патенти). Софт вже досить стабільний, можна спробувати, заміряти продуктивність і т.п. Єдина незручність - поки що потрібно вручну оновлювати конфігурацію тома і десь її зберігати.
Реалізувати свої задуми мені вдалося поки що відсотків на 10. Однак вдалося те, що я вважав найважчим — це «подружити» логічні томи з флаш-процедурою, яка виконує всі відкладені дії в reiser4. Це все поки що в експериментальній гілці «format41».
Чи проходить Reiser4 тести xfstests?
Принаймні у мене пройшла, коли я готував останній випуск.
Чи можливо в принципі за допомогою плагінів зробити Reiser4 мережевою (кластерною) ФС?
Можна і навіть потрібно! Якщо на основі правильно спроектованої локальної ФС створити мережеву, результат буде дуже вражаючим! У сучасних мережевих ФС мене не влаштовує наявність рівня backend storage, що реалізується за допомогою будь-якої локальної ФС. Існування цього рівня зовсім невиправдане. Мережева ФС повинна нормально взаємодіяти з block layer, і не просити локальну ФС створити ще якісь там службові файли!
Взагалі, розподіл файлових систем на локальні та мережеві - це від лукавого. Воно виникло від недосконалості алгоритмів, якими користувалися тридцять років тому і замість яких досі нічого не було запропоновано. Це є причиною появи маси непотрібних софтверних компонет (різних сервісів і т.д). По-хорошому, повинна бути тільки одна ФС у вигляді модуля ядра і набору утиліт, що інсталюються на кожній машині — вузлі кластера. Ця ФС одночасно і локальна та мережева. І нічого зайвого!
Якщо з Reiser4 в Linux'і так нічого і не вийде, хотілося б запропонувати ФС для FreeBSD (цитата з минулого інтерв'ю: «… FreeBSD … має академічне коріння… А це означає, що з великою ймовірністю ми знайдемо з розробниками спільну мову») ?
Отже, як ми щойно з'ясували, з Лінуксом у нас все вже чудово вийшло: під нього є окремий порт Reiser4 у вигляді майстер-бранча нашого репозиторію. Про FreeBSD я й не забув! Пропонуйте! Готовий щільно попрацювати з тими, хто добре знає нутрощі FreeBSD. До речі: що мені дуже подобається в їхньому співтоваристві — там рішення приймаються оновлюваною радою незалежних експертів, яка не має нічого спільного з губонадувством однієї незмінної персони.
Як ти оцінюєш спільноту користувачів Linux сьогодні? Чи стало воно більш «попсовим»?
Мені за своєю діяльністю оцінити таке досить важко. До мене в основному приходять користувачі з багрепортами та проханнями полагодити розділ. Користувачі як користувачі. Хтось підкований більше, хтось менший. До всіх ставлення однакове. Ну, а якщо користувач ігнорує мої вказівки, то вже вибачте: ігнор буде введений і з мого боку.
Чи можливо спрогнозувати розвиток файлових систем на п'ять-десять років? Які, на твою думку, основні виклики можуть стояти перед розробниками ФС?
Так, зробити такий прогноз нескладно. В апстрім давно вже немає ніякого розвитку файлових систем. Створюється лише видимість такого. Розробники локальних ФС уперлися у проблеми пов'язані з невдалим дизайном. Тут треба зробити застереження. Т.зв. «зберігання», «вилизування» та портування коду я за розвиток і розробку не вважаю. А непорозуміння під назвою «Btrfs» до розробок не зараховую через причини, які я вже пояснив.
Кожен патч лише посилює її проблеми. Ну. і завжди є різного роду «євангелісти», у яких «все працює». В основному, це школярі та студенти, які прогулюють лекції. Ви тільки уявіть: у нього працює, а у професора немає. Це який викид адреналіну! Найбільшу ж шкоду з мого погляду завдають «умільці», що кинулися з ентузіазмом «пригвинчувати» чудо-фічі Btrfs до всіляких прошарків типу systemd, docker і т.п. - це вже нагадує метастази.
Давайте спробуємо зробити прогноз на п'ять-десять років. Що ми робитимемо у Reiser4 я коротко вже перерахував. Основним викликом для розробників локальних ФС з апстріму стане неможливість займатися пристойною справою за зарплату. Без будь-яких ідей у сфері зберігання даних вони продовжуватимуть намагатися патчити ці нещасні VFS, XFS та ext4. Особливо комічно на цьому тлі виглядає ситуація з VFS, що нагадує розлючену модернізацію ресторану, в якому кухарів немає, і не передбачається.
Тепер код VFS без будь-яких умов залочує одночасно кілька сторінок пам'яті і пропонує ФС оперувати над ними. Це було введено для підвищення продуктивності Ext4 на операціях видалення, але, як неважко зрозуміти, такий одночасний лок абсолютно несумісний з сучасними транзакційними моделями. Тобто додати підтримку якоїсь розумної ФС в ядрі ви вже просто так не зможете. Я не знаю, як іде в інших областях Linux, але що стосується файлових систем, якийсь розвиток тут навряд чи сумісний з політикою, що проводиться Торвальдсом насправді (академічні проекти виганяються, а шахраям, які не мають поняття, що таке B-дерево , Видаються нескінченні кредити довіри). Тому тут узяли курс на повільне загнивання. Його, звичайно ж, щосили намагатимуться видати за «розвиток».
Далі, «зберігачі» файлових систем, зрозумівши, що на одному лише «зберіганні» багато не заробиш, пробуватимуть себе у більш прибутковому бізнесі. Це, як правило, розподілені файлові системи та віртуалізація. Можливо, кудись ще портуватимуть модну ZFS там, де її ще немає. Але вона, як і всі ФС з апстріму, нагадує новорічну ялинку: якщо згори ще щось із дрібниці повісити можна, то глибше вже не підлізеш. Я припускаю, що побудувати серйозну ентерпрайз-систему на базі ZFS можна, але оскільки ми зараз обговорюємо майбутнє, то мені залишається з жалем констатувати, що ZFS у цьому плані безнадійна: своїми віртуальними девайсами хлопці перекрили собі і майбутнім поколінням кис. ZFS це вчорашній день. А ext4 і XFS вже навіть не позавчорашній.
Окремо варто сказати про поняття «Linux file system of next generation». Це повністю політичний і маркетинговий проект, створений для можливості, скажімо, «стовпити майбутнє файлових систем» в Linux за конкретними персонажами. Справа в тому, що це раніше Linux був "just for fun". А зараз це насамперед машина для заробляння грошей. Вони робляться на всьому, на чому тільки можна. Наприклад, створити хороший програмний продукт дуже важко, але тямущі «розробники» давно вже зрозуміли, що напружуватися зовсім не потрібно: успішно продавати можна і неіснуючий софт, анонсований і розпіарений на всіляких публічних заходах — головне, щоб у презентаційних слайдах було більше «фіч».
Файлові системи підходять для цього якнайкраще, бо на результат можна сміливо виторговувати років десять. Ну, а якщо хтось потім нарікатиме на відсутність цього самого результату, то він же у файлових системах просто нічого не тямить! Це нагадує фінансову піраміду: на вершині розташовуються авантюристи, що заварили цю кашу, і ті небагато, кому «пощастило»: вони «зняли дивіденди», тобто. отримали гроші на розробку, влаштувалися менеджерами на високооплачувану роботу, «засвітилися» на конференціях тощо.
Далі йдуть ті, кому «не пощастило»: вони підраховуватимуть збитки, розхльобуватимуть наслідки розгортання у продакшн непридатного програмного продукту», тощо. Їх набагато більше. Ну, і в основі піраміди - величезна маса розробників, що «пиляють» нікчемний код. Вони — у найбільшому програші, бо марно витрачений час не повернеш. Такі піраміди надзвичайно вигідні Торвальдсу та його наближеним. І що цих пірамід більше — то їм краще. Для підживлення таких пірамід в ядро може бути прийнято що завгодно. Зрозуміло, на публіці вони стверджують протилежне. Але я суджу не за словами, а за вчинками.
Так що, «майбутнє файлових систем в Лінукс» — це ще один сильно розпиарений, але мало придатний для використання софт. Після Btrfs з великою ймовірністю місце такого «майбутнього» займе Bcachefs, що є ще однією спробою схрестити Linux block layer з файловою системою (поганий приклад заразливий). І що характерно: там ті самі проблеми, що й у Btrfs. Я давно це підозрював, а потім якось не втримався і заглянув у код — так і є!
Автори Bcachefs та Btrfs, створюючи свої ФС, активно користувалися чужими вихідниками, мало що в них розуміючи. Ситуація дуже нагадує дитячу гру зіпсований телефон. І я приблизно уявляю, як відбуватиметься включення цього коду до ядра. Власне «граблі» ніхто не побачить (на них усі наступатимуть потім). Після численних причіпок до стилю коду коду, звинувачення в неіснуючих порушеннях, тощо буде робитися висновок про «лояльність» автора, про те, наскільки він добре «взаємодіє» з іншими розробниками, і як успішно все це потім можна буде продавати корпораціям.
Кінцевий результат нікого не зацікавить. Років двадцять тому, можливо, б і зацікавив, але зараз питання ставляться інакше: чи вдасться це розкрутити так, щоб найближчий десяток років певні люди були працевлаштовані. А запитувати про кінцевий результат, на жаль, не прийнято.
А взагалі, я б не рекомендував починати винаходити свою файлову систему «з нуля». Бо навіть суттєвих фінансових вкладень буде недостатньо, щоб років за десять отримати щось конкурентоспроможне. Зрозуміло, я говорю про серйозні проекти, а не про ті, які призначені для «проштовхування» в ядро. Отже, ефективніший спосіб заявити про себе — це приєднатися до реальних розробок, наприклад, до нас. Зробити це, зрозуміло, непросто — але така ситуація з будь-яким проектом високого рівня.
Спочатку потрібно буде самостійно здолати завдання, яке я запропоную. Після цього, переконаний у серйозності ваших намірів, я почну допомагати. Традиційно ми використовуємо лише власні напрацювання. Виняток становлять алгоритми компресії та деякі хеш-функції. Ми не відправляємо розробників колесити по конференціях, а потім не сидимо і не комбінуємо чужі ідеї («а може, чого і вийде»), як це прийнято в більшості стартапів.
Усі алгоритми ми розробляємо самі. Зараз мене цікавлять алгебраїчні та комбінаторні аспекти науки зберігання даних. Зокрема кінцеві поля, асимптотика, доказ нерівностей. Для простих програмістів теж знайдеться робота, однак маю відразу попередити: всі пропозиції «подивитися на іншу ФС і зробити так само» вирушають у ігнор. Туди підуть патчі, спрямовані на більш тісну інтеграцію з Linux по лінії VFS.
Отже, ми не маємо граблів, а є розуміння, куди треба рухатися, і є впевненість, що цей напрямок правильний. Таке розуміння не прийшло у вигляді небесної манни. Я нагадаю, що за 29-річним досвідом розробок, дві файлові системи написані «з нуля». І стільки ж утиліта відновлення даних. А це дуже багато!
Джерело: opennet.ru