Публикувано е второто интервю с Едуард Шишкин, разработчик на файловата система Reiser4.
Като начало, моля, напомнете на читателите къде и за кого работите.
Работя като главен архитект за съхранение в Huawei Technologies, Германски изследователски център. В отдела за виртуализация се занимавам с различни аспекти на съхранението на данни. Моите дейности не са свързани с конкретна операционна система.
В момента ангажирате ли се с основния клон на ядрото?
Много рядко и само ако работодателят ми го изисква. Последният път беше преди около три години, изпратих корекции за увеличаване на пропускателната способност за съхранение, споделено на хостове, използващи протокола 9p (друго име за този бизнес е VirtFS). Тук трябва да направя една важна забележка: въпреки че работя с Linux от дълго време, никога не съм му бил фен, тоест „дишам равномерно“, както и с всичко останало. По-специално, ако забележа недостатък, мога да го посоча най-много веднъж. И за да можеш след това да последваш някого и да го убеждаваш - това няма да стане.
Спомням си последния път, преди десет години, бяхте доста критични към стила на разработка на ядрото. От ваша (или може би корпоративна) гледна точка промени ли се нещо, общността стана ли по-отзивчива или не? Ако не, кой мислите, че е виновен?
Никога не съм виждал промени към по-добро. Основният проблем на общността е подмяната на науката с политически технологии, лични отношения, мнение на мнозинството, популизъм, съвети от „вътрешни гласове“, гнили компромиси, всичко друго освен наука. Информатиката, каквото и да се каже, е преди всичко точна наука. И ако някой започне да провъзгласява собствената си стойност за 2x2, различна от 4, под флага "Linux way" или под някакъв друг флаг, тогава това едва ли ще донесе нещо друго освен вреда.
Всички проблеми се дължат преди всичко на некомпетентността и необразоваността на тези, които вземат решения. Ако един мениджър е некомпетентен, той не може да вземе обективно, адекватно решение. Ако е и некултурен, не е в състояние да намери компетентен специалист, който да го посъветва правилно. С голяма вероятност изборът ще падне върху измамник, който казва „привидно правилни неща“. Корумпираната среда винаги се развива около некомпетентни самотни лидери. Освен това историята не познава изключения в това отношение и общността е най-яркото потвърждение за това.
Как оценявате напредъка в развитието на Btrfs? Този ФС отърва ли детските болести? Как го позиционирате за себе си - като FS „за дома“ или и за корпоративна употреба?
Не се отървах от него. Всичко, което споменах преди 11 години, е актуално и днес. Един от проблемите на Btrfs, който го прави неподходящ за сериозни нужди, е проблемът със свободното пространство. Дори не говоря за факта, че потребителят е помолен да изтича до магазина за нов диск в ситуации, когато всяка друга FS би показала много свободно място на дяла. Невъзможността да завършите операция на логически том поради липса на свободно място също не е най-лошото нещо. Най-лошото е, че непривилегирован потребител може почти винаги, заобикаляйки всякакви дискови квоти, да лиши всички от свободно пространство за сравнително кратко време.
Изглежда така (тествано за Linux ядро 5.12). На прясно инсталирана система се стартира скрипт, който в цикъл създава файлове с определени имена в началната директория, записва данни в тях при определени отмествания и след това изтрива тези файлове. След минута изпълнение на този скрипт не се случва нищо необичайно. След пет минути частта от заетото пространство на дяла леко се увеличава. След два до три часа достига 50% (при първоначална стойност 15%). И след пет или шест часа работа, скриптът се срива с грешката „няма свободно място на дяла“. След това вече не можете да запишете дори 4K файл на вашия дял.
Възниква интересна ситуация: в крайна сметка не сте написали нищо в дяла и цялото свободно пространство (около 85%) изчезна някъде. Анализът на раздел, обект на такава атака, ще разкрие много възли на дърво, съдържащи само един елемент (обект, оборудван с ключ), с размер няколко байта. Тоест съдържанието, което преди това заемаше 15% от дисковото пространство, се оказа равномерно „размазано“ по целия дял, така че няма къде да напишете нов файл, тъй като неговият ключ е по-голям от всички съществуващи, а свободният блоковете на дяла са свършили.
Освен това всичко това се случва вече в основната конфигурация на Btrfs (без никакви моментни снимки, подтомове и т.н.) и няма значение как решите да съхранявате файлови тела в тази FS (като „фрагменти“ в дърво или като екстенти на неформатирани блокове) - крайният резултат ще бъде същият.
Няма да можете да подложите други файлови системи нагоре по веригата на такава атака (без значение какво ви казват). Отдавна обясних причината за проблема: това е пълно извращение на концепцията на B-дървото в Btrfs, което прави възможно нейното спонтанно или умишлено израждане. По-специално, при определени натоварвания, вашата файлова система непрекъснато ще се „разпада“ по време на работа сама, без външна помощ. Ясно е, че всички видове „натискащи“ фонови процеси ще спасят деня само на отделни настолни компютри.
На колективните сървъри нападателят винаги ще може да ги „изпревари“. Системният администратор дори няма да може да определи кой точно го е тормозил. Най-бързият начин да коригирате този проблем в Btrfs е да възстановите структурата на редовно B-дърво, т.е. редизайн на дисковия формат и пренаписване на значителни части от Btrfs кода. Това ще отнеме 8-10 години, включително отстраняване на грешки, при условие че разработчиците са следвали стриктно оригиналните статии за съответните алгоритми и структури от данни и не са играли на играта „развален телефон“, както е обичайно (и насърчавано) в „Linux начин”.
Тук също трябва да добавим времето, необходимо на разработчиците да разберат всичко това. Тук става по-трудно. Във всеки случай 10 години не им стигнаха, за да разберат. Е, дотогава не можете да се надявате на чудо. Това няма да се случи под формата на опция за монтиране, „за която вие и аз не знаехме“ или под формата на кръпка, която е „просто бизнес въпрос“ за подготовка. За всяка такава прибързана „поправка“ ще представя нов сценарий на израждане. B-дърветата са една от любимите ми теми и трябва да кажа, че тези структури не търпят волности със себе си!
Как да позиционирам Btrfs за себе си? Като нещо, което абсолютно не може да се нарече файлова система, камо ли да се използва. Тъй като по дефиниция FS е подсистема на ОС, отговорна за ефективното управление на ресурса „дисково пространство“, което не виждаме в случая на Btrfs. Ами представете си, че сте дошли в магазина да си купите часовник, за да не закъснеете за работа, а вместо часовник ви продадат електрическа скара с таймер за максимум 30 минути. Така че ситуацията с Btrfs е още по-лоша.
Преглеждайки пощенските списъци, често срещам твърдението, че ефективното управление на дисковото пространство вече не е от значение поради евтиността на устройствата. Това са пълни глупости. Без ефективен мениджър на дисково пространство операционната система ще стане уязвима и неизползваема. Независимо от капацитета на дисковете на вашата машина.
Бих искал да помоля за коментар относно прекратяването на поддръжката на Btrfs в RHEL.
Тук няма какво специално да коментираме, всичко е много ясно. Имаха го и като „преглед на технологията“. И така, не минах през този „предварителен преглед“. Не позволявайте този етикет да виси вечно! Но те не могат да пуснат продукт с недостатъци в дизайна с пълна поддръжка. 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. Спомням си, че беше проведено изследване от този вид: на някои файлови системи от upstream бяха създадени огромен брой обекти на дискове от висок клас от ново поколение. Според резултатите XFS се държи по-добре от ext4. Така те започнаха да го рекламират като най-обещаващ. Във всеки случай не бих търсил нищо сензационно тук.
За мен все едно са заменили шилото със сапун. Няма смисъл да се разработва ext4 и XFS. И двете паралелно и всяка от тях по избор. Нищо добро няма да излезе от това. Въпреки че в природата често има ситуации, когато има много потенциал за растеж, но няма място за растеж. В този случай възникват различни странни грозни новообразувания, към които всички сочат с пръст („О, вижте, какво няма да видите в този живот!“).
Мислите ли, че проблемът с нарушаването на слоя е решен (в негативен смисъл) с появата на функциите за криптиране в ext4, F2FS (да не говорим за RAID в Btrfs)?
По принцип въвеждането на каквито и да било нива и вземането на решение за тяхното ненарушаване обикновено е въпрос на политика и не се наемам да коментирам нищо тук. Обективните аспекти на нарушението на слоя са от малък интерес за никого, но можем да разгледаме някои от тях, като използваме примера за нарушение „отгоре“, а именно внедряването във FS на функционалност, която вече съществува на блоковия слой. Подобно „нарушение“ е оправдано само с редки изключения. За всеки такъв случай първо трябва да докажете две неща: че наистина е необходимо и че дизайнът на системата няма да бъде наранен от това.
Например дублирането, което традиционно е било дейност за блоковия слой, има смисъл да се прилага на ниво файлова система. По различни причини. Например, „безшумно“ повреждане на данни (bit rot) възниква на дискови устройства. Това е, когато устройството работи правилно, но блоковите данни са неочаквано повредени под въздействието на силен гама квант, излъчен от далечен квазар и др. Най-лошото е, ако този блок се окаже системен блок на FS (суперблок, растерен блок, възел на дървото за съхранение и т.н.), защото това със сигурност ще доведе до паника в ядрото.
Моля, имайте предвид, че огледалата, предлагани от блоковия слой (т.нар. RAID 1), няма да ви спасят от този проблем. Е, наистина: някой трябва да провери контролните суми и да прочете репликата в случай на повреда? Освен това има смисъл да отразявате не само всичко, но само метаданните. Някои важни данни (например изпълними файлове на критични приложения) могат да се съхраняват като метаданни. В този случай те получават същите гаранции за безопасност. Има смисъл да поверите защитата на останалите данни на други подсистеми (може би дори потребителски приложения) - ние сме осигурили всички необходими условия за това.
Такива „икономични“ огледала имат право на съществуване и могат да бъдат организирани ефективно само на ниво файлова система. В противен случай нарушението на наслояването е претрупване на подсистема с дублиран код в името на някои микроскопични ползи. Ярък пример за това е внедряването на RAID-5 с помощта на FS. Такива решения (собствен RAID / LVM във файловата система) убиват последната в архитектурно отношение. Тук също трябва да се отбележи, че нарушението на наслояването се „пуска на поток“ от различни видове маркетингови измамници. При липса на идеи към подсистемите се добавя функционалност, която отдавна е внедрена на съседни нива, това се представя като нова изключително полезна функция и се прокарва активно.
Reiser4 беше обвинен в нарушаване на нивата „отдолу“. Въз основа на факта, че файловата система не е монолитна, като всички останали, а модулна, беше направено необосновано предположение, че тя прави това, което трябва да прави нивото по-горе (VFS).
Може ли да се говори за смъртта на ReiserFS v3.6 и например JFS? Напоследък почти не им се обръща внимание в ядрото. Остарели ли са?
Тук трябва да дефинираме какво означава смъртта на софтуерен продукт. От една страна, те се използват успешно (все пак за това са създадени), което означава, че живеят. От друга страна, не мога да говоря за JFS (не знам много), но ReiserFS (v3) е много трудно да се адаптира към новите тенденции (тествано на практика). Това означава, че в бъдеще разработчиците ще обърнат внимание не на него, а на тези, които са по-лесни за адаптиране. От тази страна се оказва, че, уви, той е мъртъв в архитектурно отношение. Изобщо не бих манипулирал понятието „морално остарял“. Прилага се добре, например, за гардероб, но не и за софтуерни продукти. Има концепция за малоценност и превъзходство в нещо. Абсолютно мога да кажа, че ReserFS v3 сега е по-нисък от Reiser4 във всичко, но при някои типове натоварване превъзхожда всички други FS нагоре по веригата.
Знаете ли за разработката на FS Tux3 и HAMMER/HAMMER2 (FS за DragonFly BSD)?
Да, знаем. В Tux3 някога се интересувах от технологията на техните снимки (така наречените „указатели на версии“), но в Reiser4 най-вероятно ще тръгнем по друг път. Отдавна обмислям поддръжката на моментни снимки и все още не съм решил как да ги внедря за прости томове на Reiser4. Факт е, че новомодната "мързелива" техника за референтен брояч, предложена от Ohad Rodeh, работи само за B-дървета. Ние ги нямаме. За онези структури от данни, които се използват в Reiesr4, „мързеливите“ броячи не са дефинирани - за въвеждането им е необходимо да се решат определени алгоритмични проблеми, които все още никой не е поел.
Според HAMMER: Прочетох статия от създателя. Не се интересувам. Отново B-дървета. Тази структура от данни е безнадеждно остаряла. Ние го изоставихме през миналия век.
Как оценявате нарастващото търсене на мрежови клъстерни FS като CephFS/GlusterFS/и т.н.? Това търсене означава ли промяна в приоритетите на разработчиците към мрежови FS и недостатъчно внимание към локалните FS?
Да, такова разместване на приоритетите се случи. Развитието на локалните файлови системи е в застой. Уви, да се направи нещо значително за местни обеми сега е доста трудно и не всеки може да го направи. Никой не иска да инвестира в тяхното развитие. Това е приблизително същото като да поискате от търговска организация да отдели пари за математически изследвания - без никакъв ентусиазъм те ще ви попитат как можете да спечелите пари от нова теорема. Сега локалният FS е нещо, което магически изглежда „извън кутията“ и „винаги трябва да работи“, а ако не работи, предизвиква ненасочено мърморене като: „Да, какво си мислят!“
Оттук и липсата на внимание към местните FS, въпреки че все още има много работа в тази област. И да, всички се насочиха към разпределеното хранилище, което е изградено на базата на вече съществуващи локални файлови системи. Сега е много модерно. Изразът „Големи данни“ предизвиква прилив на адреналин у мнозина, свързвайки го с конференции, семинари, големи заплати и т.н.
Колко разумно е по принцип да се внедри мрежовата файлова система в пространството на ядрото, а не в потребителското пространство?
Много разумен подход, който все още не е прилаган никъде. Като цяло, въпросът в какво пространство трябва да бъде внедрена мрежова файлова система е „нож с две остриета“. Е, нека да разгледаме един пример. Клиентът записва данни на отдалечена машина. Те паднаха в кеша й под формата на мръсни страници. Това е работата за мрежова файлова система "тънък шлюз" в пространството на ядрото. Тогава операционната система рано или късно ще ви помоли да запишете тези страници на диска, за да ги освободите. След това IO-пренасочващият (изпращащ) мрежов FS модул влиза в действие. Той определя към коя сървърна машина (сървърен възел) ще отидат тези страници.
Тогава мрежовият стек поема (и, както знаем, той е внедрен в пространството на ядрото). След това сървърният възел получава този пакет с данни или метаданни и инструктира модула за съхранение в задната част (т.е. локалната FS, която работи в пространството на ядрото) да запише всички тези неща. И така, сведохме въпроса до това къде трябва да работят модулите „изпращане“ и „получаване“. Ако някой от тези модули работи в потребителско пространство, това неизбежно ще доведе до превключване на контекста (поради необходимостта от използване на услуги на ядрото). Броят на тези превключватели зависи от детайлите на изпълнението.
Ако има много такива превключватели, тогава пропускателната способност на съхранението (I/O производителност) ще намалее. Ако вашето backend хранилище се състои от бавни дискове, тогава няма да забележите значителен спад. Но ако имате бързи дискове (SSD, NVRAM и т.н.), тогава превключването на контекст вече се превръща в „тясно място“ и чрез спестяване на превключване на контекст производителността може да се увеличи значително. Стандартният начин да спестите пари е да преместите модули в пространството на ядрото. Например открихме, че преместването на 9p сървъра от QEMU към ядрото на хост машината води до трикратно увеличение на производителността на VirtFS.
Това, разбира се, не е мрежов FS, но напълно отразява същността на нещата. Недостатъкът на тази оптимизация са проблемите с преносимостта. За някои последното може да е критично. Например GlusterFS изобщо няма модули в ядрото. Благодарение на това сега работи на много платформи, включително NetBSD.
Какви концепции биха могли да заемат местните FS от мрежовите и обратно?
В днешно време мрежовите FS по правило имат добавки към локалните FS, така че не разбирам съвсем как можете да заимствате нещо от последните. Е, наистина, нека разгледаме компания от 4 служители, в която всеки си върши работата: един разпространява, друг изпраща, трети получава, четвърти съхранява. И въпросът, какво може да заеме компанията от своя служител, който го съхранява, звучи някак некоректно (тя вече има това, което можеше да заеме от него отдавна).
Но местните FS имат какво да научат от мрежовите. Първо, трябва да научите от тях как да агрегирате логически томове на високо ниво. Сега т.нар „Разширените“ локални файлови системи агрегират логически томове изключително с помощта на технологията „виртуално устройство“, заимствана от LVM (същото нарушение на инфекциозното наслояване, което беше въведено за първи път в ZFS). С други думи, преобразуването на виртуални адреси (блокови номера) в реални и обратно се извършва на ниско ниво (т.е. след като файловата система е издала I/O заявка).
Моля, обърнете внимание, че добавянето и премахването на устройства към логически томове (не огледални), подредени на блоковия слой, води до проблеми, за които доставчиците на такива „функции“ скромно мълчат. Говоря за фрагментация на реални устройства, която може да достигне чудовищни стойности, докато на виртуално всичко е наред. Въпреки това, малко хора се интересуват от виртуални устройства: всички се интересуват от това, което се случва на вашите реални устройства. Но подобни на ZFS FS (както и всеки FS във връзка с LVM) работят само с виртуални дискови устройства (разпределете виртуални дискови адреси сред свободните, дефрагментирайте тези виртуални устройства и т.н.). И те нямат представа какво се случва на реални устройства!
Сега си представете, че имате нулева фрагментация на виртуалното устройство (т.е. имате само един гигантски екстент, живеещ там), добавяте диск към вашия логически том и след това премахвате друг произволен диск от вашия логически том и след това ребалансирате. И така много пъти. Не е трудно да си представите, че на виртуалното устройство ще продължите да живеете в същата степен, но на реални устройства няма да видите нищо добро.
Най-лошото е, че дори не сте в състояние да коригирате тази ситуация! Единственото нещо, което можете да направите тук, е да поискате от файловата система да дефрагментира виртуалното устройство. Но тя ще ви каже, че там всичко е страхотно - има само една степен, фрагментацията е нула и не може да бъде по-добре! Така че логическите томове, подредени на ниво блок, не са предназначени за многократно добавяне/премахване на устройства. В добрия смисъл, трябва само веднъж да сглобите логически том на ниво блок, да го дадете на файловата система и след това да не правите нищо друго с него.
В допълнение, комбинацията от независими подсистеми FS+LVM не позволява да се вземе предвид различното естество на устройствата, от които се агрегират логическите томове. Наистина, да предположим, че сте сглобили логически том от HDD и твърдотелни устройства. Но тогава първото ще изисква дефрагментиране, а второто не. За второто трябва да издавате заявки за изхвърляне, но за първото не и т.н. Въпреки това, в тази комбинация е доста трудно да се демонстрира такава селективност.
Имайте предвид, че след като създадете свой собствен LVM на файловата система, ситуацията не се подобрява много. Освен това, правейки това, вие всъщност слагате край на перспективата някога да го подобрите в бъдеще. Това е много лошо. Различни типове дискове могат да работят на една и съща машина. И ако файловата система не прави разлика между тях, тогава кой ще го направи?
Друг проблем дебне т.нар. Файлови системи „Write-Anywhere“ (това включва също Reiser4, ако сте посочили подходящия транзакционен модел по време на монтирането). Такива файлови системи трябва да предоставят инструменти за дефрагментиране, които са безпрецедентни по силата си. И мениджърът на звука на ниско ниво не помага тук, а само пречи. Факт е, че с такъв мениджър вашият FS ще съхранява карта на свободните блокове само на едно устройство - виртуално. Съответно можете да дефрагментирате само виртуално устройство. Това означава, че вашият дефрагментатор ще работи дълго, дълго време върху огромно единично пространство от виртуални адреси.
И ако имате много потребители, които извършват произволни презаписи, тогава полезният ефект от такъв дефрагментатор ще бъде намален до нула. Вашата система неизбежно ще започне да се забавя и ще трябва само да скръстите ръце пред разочароващата диагноза „счупен дизайн“. Няколко дефрагментиращи програми, работещи в едно и също адресно пространство, само ще си пречат. Съвсем различен е въпросът, ако поддържате своя собствена карта на безплатни блокове за всяко реално устройство. Това ефективно ще паралелизира процеса на дефрагментиране.
Но това може да стане само ако имате мениджър на логически томове от високо ниво. Локалните файлови системи с такива мениджъри не са съществували преди (поне аз не знам за тях). Само мрежовите файлови системи (например GlusterFS) имаха такива мениджъри. Друг много важен пример е помощната програма за проверка на целостта на тома (fsck). Ако съхранявате своя собствена независима карта на свободни блокове за всеки подтом, тогава процедурата за проверка на логически том може да бъде ефективно успоредна. С други думи, логическите томове с мениджъри на високо ниво се мащабират по-добре.
Освен това с мениджърите на обеми на ниско ниво няма да можете да организирате пълноценни моментни снимки. С файлови системи, подобни на LVM и ZFS, можете да правите само локални моментни снимки, но не и глобални моментни снимки. Локалните моментни снимки ви позволяват незабавно да върнете назад само редовни файлови операции. И никой там няма да връща назад операции с логически томове (добавяне/премахване на устройства). Нека да разгледаме това с пример. В даден момент, когато имате логически том от две устройства A и B, съдържащ 100 файла, вие правите моментна снимка на системата S и след това създавате други сто файла.
След това добавяте устройство C към вашия том и накрая връщате системата си към моментна снимка S. Въпрос: Колко файла и устройства съдържа вашият логически том след връщане към S? Ще има 100 файла, както може би се досещате, но ще има 3 устройства - това са едни и същи устройства A, B и C, въпреки че по време на създаването на снимката е имало само две устройства в системата (A и B ). Операцията за добавяне на устройство C не се върна назад и ако сега премахнете устройство C от компютъра, това ще повреди данните ви, така че преди да изтриете, ще трябва първо да извършите скъпа операция за премахване на устройството от логическия том за повторно балансиране, което ще разпръсне всички данни от устройство C към устройства A и B. Но ако вашият FS поддържа глобални моментни снимки, няма да е необходимо такова повторно балансиране и след незабавно връщане назад към S можете безопасно да премахнете устройство C от компютъра.
И така, глобалните моментни снимки са добри, защото ви позволяват да избегнете скъпото премахване (добавяне) на устройство от логически том (към логически том) с голямо количество данни (разбира се, ако не забравяте да направите „моментна снимка“ на вашата система в правилното време). Нека ви напомня, че създаването на моментни снимки и връщането на файловата система към тях са мигновени операции. Може да възникне въпросът: как изобщо е възможно незабавно да върнете назад операция на логически том, която ви е отнела три дни? Но е възможно! При условие, че вашата файлова система е проектирана правилно. Идеята за такива „3D снимки“ ми хрумна преди три години, а миналата година патентовах тази техника.
Следващото нещо, което локалните FS трябва да научат от мрежовите е да съхраняват метаданни на отделни устройства по същия начин, по който мрежовите FS ги съхраняват на отделни машини (така наречените сървъри за метаданни). Има приложения, които работят предимно с метаданни, и тези приложения могат да бъдат значително ускорени чрез поставяне на метаданните на скъпи високопроизводителни устройства за съхранение. С комбинацията FS+LVM няма да можете да демонстрирате такава селективност: LVM не знае какво има в блока, който сте му предали (данни там или метаданни).
Няма да получите голяма полза от внедряването на собствен LVM на ниско ниво във FS в сравнение с комбинацията FS+LVM, но това, което можете да направите много добре, е да претрупате FS, така че по-късно да стане невъзможно да работите с неговия код. ZFS и Btrfs, които се втурнаха с виртуални устройства, са ясни примери за това как нарушението на наслояването убива системата от архитектурно отношение.И така, защо ми е всичко това? Освен това, няма нужда да изграждате свой собствен LVM на ниско ниво във файловата система. Вместо това трябва да обедините устройства в логически томове на високо ниво, както правят някои мрежови файлови системи с различни машини (възли за съхранение). Вярно е, че правят това отвратително поради използването на лоши алгоритми.
Примери за абсолютно ужасни алгоритми са DHT транслаторът във файловата система GlusterFS и така наречената CRUSH карта във файловата система Ceph. Нито един от алгоритмите, които видях, не ме удовлетвори от гледна точка на простота и добра скалируемост. Така че трябваше да си спомня алгебрата и да измисля всичко сам. През 2015 г., докато експериментирах с пакети върху хеш функции, измислих и патентовах нещо, което ми пасва. Сега мога да кажа, че опитът да се приложи всичко това на практика беше успешен. Не виждам никакви проблеми с мащабируемостта в новия подход.
Да, всеки подтом ще изисква отделна структура като суперблок в паметта. Това много ли е страшно? Като цяло не знам кой ще „свари океана“ и ще създаде логически обеми от стотици хиляди или повече устройства на една локална машина. Ако някой може да ми обясни това, ще съм много благодарен. Междувременно за мен това са маркетингови глупости.
Как промените в подсистемата на блоковото устройство на ядрото (например появата на blk-mq) повлияха на изискванията за внедряване на FS?
Не оказаха никакво влияние. Не знам какво би се случило на блоковия слой, което би наложило проектирането на нов FS. Интерфейсът за взаимодействие на тези подсистеми е много лош. От страна на драйвера, FS трябва да бъде засегнат само от появата на нови типове устройства, към които първо ще се настрои блоковият слой, а след това FS (за reiser4 това ще означава появата на нови добавки).
Означава ли появата на нови видове носители (например SMR или повсеместното разпространение на SSD) фундаментално нови предизвикателства за дизайна на файловата система?
да И това са нормални стимули за развитие на ФС. Предизвикателствата могат да бъдат различни и напълно неочаквани. Например, чувал съм за устройства, при които скоростта на I/O операция е силно зависима от размера на част от данните и нейното отместване. В Linux, където размерът на FS блока не може да надвишава размера на страницата, такова устройство няма да покаже пълните си възможности по подразбиране. Въпреки това, ако вашата файлова система е проектирана правилно, тогава има шанс да извлечете много повече от нея.
Колко души в момента работят с кода Reiser4 освен вас?
По-малко, отколкото бих искал, но също така не изпитвам остър недостиг на ресурси. Повече от доволен съм от темпото на развитие на Reiser4. Няма да „карам коне“ - това не е правилната област. Ето, "ако караш по-тихо, ще продължиш!" Модерната файлова система е най-сложната подсистема на ядрото, чиито грешни дизайнерски решения могат да отменят следващите години човешка работа.
Като предлагам на доброволци да реализират нещо, винаги гарантирам, че усилията със сигурност ще доведат до правилния резултат, който може да бъде търсен при сериозни нужди. Както разбирате, не може да има много такива гаранции наведнъж. В същото време не мога да понасям „фигури“, които безсрамно популяризират „функции“ на очевидно неизползваем софтуер, заблуждавайки стотици потребители и разработчици, и в същото време седят и се усмихват на срещи на върха на ядрото.
Някоя компания изразила ли е желание да подкрепи развитието на Reiser4?
Да, имаше такива предложения, вкл. и от основен доставчик. Но за това трябваше да се преместя в друга държава. За съжаление вече не съм на 30 години, не мога да се откъсна и да си тръгна така при първия сигнал.
Какви функции в момента липсват на Reiser4?
Няма функция за „преоразмеряване“ за прости томове, подобна на тази в ReiserFS(v3). В допълнение, файловите операции с флага DIRECT_IO не биха навредили. След това бих искал да мога да разделя том на „семантични подобеми“, които нямат фиксиран размер и които могат да бъдат монтирани като независими томове. Тези проблеми са добри за начинаещи, които искат да опитат ръката си в „истинското нещо“.
И накрая, бих искал да имам мрежови логически томове с проста реализация и администриране (съвременните алгоритми вече позволяват това). Но това, което Reiser4 определено никога няма да има, е RAID-Z, скрабове, кешове за свободно пространство, 128-битови променливи и други маркетингови глупости, възникнали на фона на недостига на идеи сред разработчиците на някои файлови системи.
Може ли всичко, което може да е необходимо, да бъде реализирано чрез добавки?
Ако говорим само по отношение на интерфейси и плъгини (модули), които ги реализират, то не всичко. Но ако също така въведете връзки в тези интерфейси, тогава, наред с други неща, ще имате концепциите за по-високи полиморфизми, с които вече можете да се справите. Представете си, че хипотетично сте замразили обектно-ориентирана система за изпълнение, променили сте стойността на указателя на инструкцията, за да сочи към друг плъгин, който имплементира същия X интерфейс, и след това сте размразили системата, така че да продължи да се изпълнява.
Ако крайният потребител не забележи такова „заместване“, тогава казваме, че системата има полиморфизъм от нулев порядък в X интерфейса (или системата е хетерогенна в X интерфейса, което е едно и също нещо). Ако сега имате не само набор от интерфейси, но и връзки към тях (интерфейсна графика), тогава можете да въведете полиморфизми от по-високи порядки, които ще характеризират хетерогенността на системата, която вече е в „съседството“ на всеки интерфейс. Аз въведох такава класификация отдавна, но, за съжаление, така и не се случи.
Така че с помощта на плъгини и такива по-високи полиморфизми можете да опишете всяка известна характеристика, както и да „предскажете“ тези, които дори не са били споменавани. Не успях стриктно да докажа това, но все още не знам за контрапример. Като цяло този въпрос ми напомни за „Ерлангенската програма“ на Феликс Клайн. По едно време той се опита да представи цялата геометрия като клон на алгебрата (по-специално теорията на групите).
Сега към основния въпрос - как вървят нещата с промоцията на Reiser4 към основното ядро? Имаше ли публикации за архитектурата на тази файлова система, за която говорихте в последното интервю? Колко уместен е този въпрос от ваша гледна точка?
Общо взето от три години молим за включване в основния клон. Последният коментар на Reiser в публичната нишка, където беше направена заявката за изтегляне, остана без отговор. Така че всички допълнителни въпроси не са за нас. Аз лично не разбирам защо трябва да се „слеем“ в конкретна операционна система. На Linux светлината не се събираше като клин. Така че има отделно хранилище, в което ще има няколко клона-портове за различни операционни системи. Който има нужда, може да клонира съответния порт и да прави каквото иска с него (в рамките на лиценза, разбира се). Е, ако някой не се нуждае от това, това не е мой проблем. На този етап предлагам да разгледаме въпроса за „повишаване в основното ядро на Linux“ за уреден.
Публикациите за FS архитектура са подходящи, но засега съм намерил време само за новите си резултати, които смятам за по-приоритетни. Друго нещо е, че аз съм математик, а в математиката всяка публикация е обобщение на теореми и техните доказателства. Публикуването на каквото и да било там без доказателства е проява на лош вкус. Ако старателно докажа или опровергая всяко твърдение за архитектурата на FS, тогава резултатът ще бъде такава купчина, че ще бъде доста трудно да се премине. Кому е нужно? Вероятно затова всичко продължава да си остава в стария си вид - изходният код и коментарите към него.
Какво е новото в Reiser4 през последните няколко години?
Дългоочакваната стабилност най-накрая се материализира. Един от последните, които се появиха, беше грешка, която доведе до „неизтриваеми“ директории. Трудността беше, че се появи само на фона на сблъсъци на хеш имена и с определено местоположение на записи на директория в дървовиден възел. Все още обаче не мога да препоръчам Reiser4 за производство: за това трябва да свършите малко работа с активно взаимодействие с администраторите на производствена система.
Най-накрая успяхме да реализираме нашата дългогодишна идея - различни модели на транзакции. Преди това Reiser4 работеше само с един твърдо кодиран модел Macdonald-Reiser. Това създаде проблеми с дизайна. По-специално, моментните снимки не са възможни в такъв транзакционен модел - те ще бъдат повредени от атомен компонент, наречен „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). Отбелязвам, че функционалността на блоковия слой, наречена bcache, изобщо не предоставя такава свобода на действие. Новите логически томове са базирани на моите алгоритми (има съответни патенти). Софтуерът вече е доста стабилен, напълно възможно е да го изпробвате, да измерите производителността и т.н. Единственото неудобство е, че засега трябва ръчно да актуализирате конфигурацията на тома и да я съхранявате някъде.
Досега успях да реализирам идеите си с 10 процента, но успях в това, което смятах за най-трудно - свързването на логически томове с флаш процедура, която изпълнява всички отложени действия в reiser4. Всичко това все още е в експерименталния клон „format41“.
Reiser4 преминава ли xfstests?
Поне при мен беше така, когато подготвях последното издание.
Възможно ли е по принцип да се направи Reiser4 мрежова (клъстерна) FS с помощта на добавки?
Възможно е и дори необходимо! Ако създадете мрежов файл на базата на правилно проектирана локална файлова система, резултатът ще бъде много впечатляващ! В съвременните мрежови FS не съм доволен от наличието на ниво на резервно съхранение, което се реализира с помощта на всяка локална FS. Съществуването на това ниво е напълно неоправдано. Мрежовият FS трябва директно да взаимодейства с блоковия слой и да не иска от локалния FS да създава други сервизни файлове!
Като цяло разделянето на файловите системи на локални и мрежови е от злия. Възникна от несъвършенството на алгоритмите, които бяха използвани преди тридесет години и на които все още нищо не е предложено. Това е и причината за появата на маса ненужни софтуерни компоненти (различни услуги и др.). В добрия смисъл трябва да има само един FS под формата на модул на ядрото и набор от потребителски помощни програми, инсталирани на всяка машина - клъстерен възел. Този FS е едновременно локален и мрежов. И нищо повече!
Ако нищо не работи с Reiser4 на Linux, бих искал да предложа FS за FreeBSD (цитат от предишно интервю: „...FreeBSD... има академични корени... И това означава, че с голяма степен на вероятност ние ще намери общ език с разработчиците”) ?
И така, както току-що разбрахме, всичко вече се получи перфектно с Linux: има отделен работещ Reiser4 порт за него под формата на главен клон на нашето хранилище. Не съм забравил за FreeBSD! Оферта! Готов съм да работя в тясно сътрудничество с тези, които познават добре вътрешността на FreeBSD. Между другото: това, което много ми харесва в тяхната общност е, че там решенията се вземат от актуализиран съвет от независими експерти, което няма нищо общо с правителствената измама на един постоянен човек.
Как оценявате потребителската общност на Linux днес? Стана ли по-„поп“?
Предвид естеството на работата ми ми е доста трудно да преценя това. Предимно потребителите идват при мен с доклади за грешки и искания за коригиране на секцията. Потребителите като потребители. Някои са по-разбираеми, други по-малко. Всички се третират еднакво. Е, ако потребителят игнорира инструкциите ми, тогава ме извинете: редът за игнориране ще бъде въведен и от моя страна.
Възможно ли е да се предвиди развитието на файловите системи за следващите пет до десет години? Какви според вас са основните предизвикателства, пред които могат да се изправят разработчиците на FS?
Да, не е трудно да се направи такава прогноза. От дълго време не е имало развитие на файлови системи в upstream. Създава се само привидност на такива. Разработчиците на локални файлови системи се натъкнаха на проблеми, свързани с лош дизайн. Тук трябва да се направи едно предупреждение. Не считам така нареченото „съхранение“, „облизване“ и пренасяне на код за развитие и развитие. И не класифицирам недоразумението, наречено „Btrfs“, като развитие поради причините, които вече обясних.
Всеки пластир само влошава проблемите си. Добре. и винаги има различни видове „евангелисти“, за които „всичко работи“. По принцип това са ученици и студенти, които пропускат лекции. Само си представете: за него работи, но за професора не. Какъв адреналин е това! От моя гледна точка най-голямата вреда е причинена от „занаятчиите“, които се втурнаха да „завинтват“ с ентусиазъм прекрасните функции на Btrfs върху всякакви слоеве като systemd, docker и т.н. - това вече прилича на метастази.
Нека сега се опитаме да направим прогноза за пет до десет години. Вече описах накратко какво ще правим в Reiser4. Основното предизвикателство за местните разработчици на FS отгоре ще бъде (да, вече стана) невъзможността да се върши прилична работа срещу заплата. Без никакви идеи в областта на съхранението на данни, те ще продължат да се опитват да закърпят тези нещастни VFS, XFS и ext4. Ситуацията с VFS изглежда особено комична на този фон, напомняща за бясна модернизация на ресторант, в който готвачи няма, а готвачи не се очакват.
Сега кодът на VFS, без никакви условия, заключва няколко страници с памет едновременно и приканва основния FS да работи върху тях. Това беше въведено, за да подобри производителността на Ext4 при операции за изтриване, но както е лесно да се разбере, такова едновременно заключване е напълно несъвместимо с усъвършенстваните модели на транзакции. Тоест, няма да можете просто да добавите поддръжка за някаква интелигентна файлова система в ядрото. Не знам какво е положението в други области на Linux, но що се отнася до файловите системи, всяка разработка тук едва ли ще бъде съвместима с политиката, следвана от Torvalds на практика (академичните проекти са изгонени, а измамниците, които нямат представа какво е B-дърво, издават се безкрайни кредити на доверие). Затова беше избран курс за бавно разпадане. Разбира се, те ще се опитат с всички сили да го представят като „развитие“.
Освен това „пазителите“ на файловите системи, осъзнавайки, че не можете да спечелите много само от „съхранение“, ще опитат ръката си в по-печеливш бизнес. Това са, като правило, разпределени файлови системи и виртуализация. Може би ще пренесат модерния ZFS някъде другаде, където все още не съществува. Но той, както всички FS отгоре, прилича на новогодишно дърво: ако можете да окачите някои други малки неща отгоре, тогава не можете да стигнете по-дълбоко. Признавам, че е възможно да се изгради сериозна корпоративна система, базирана на ZFS, но тъй като сега обсъждаме бъдещето, мога само с тъга да заявя, че ZFS е безнадеждна в това отношение: с техните виртуални устройства момчетата са прекъснали кислорода за себе си и бъдещите поколения за по-нататъшно развитие. ZFS е нещо от миналото. А ext4 и XFS дори не са завчера.
Заслужава да се спомене отделно за сензационната концепция за „Linux файлова система от следващо поколение“. Това е напълно политически и маркетингов проект, създаден за възможността, така да се каже, да се „закрепи бъдещето на файловите системи“ в Linux зад конкретни символи. Факт е, че Linux преди беше „само за забавление“. Но сега това е преди всичко машина за правене на пари. Правят се на всичко възможно. Например, много е трудно да се създаде добър софтуерен продукт, но умните „разработчици“ отдавна са разбрали, че изобщо не е необходимо да се напрягате: можете успешно да продавате несъществуващ софтуер, който е обявен и популяризиран на всякакви обществени места събития - основното е слайдовете на презентацията да съдържат повече „функции“.
Файловите системи са идеални за това, защото можете спокойно да се пазарите десет години за резултата. Е, ако някой по-късно се оплаква от липсата на този резултат, той просто не разбира нищо от файловите системи! Това напомня на финансова пирамида: на върха са авантюристите, които започнаха тази бъркотия, и онези малцина, които имаха „късмет“: те „изтеглиха дивиденти“, т.е. получаваха пари за развитие, получаваха добре платена работа като мениджъри, „показваха“ се на конференции и т.н.
Следват онези, които нямат късмет: те ще преброят загубите, ще се справят с последствията от внедряването на неизползваем софтуерен продукт в производство и т.н. Те са много повече. Е, в основата на пирамидата има огромна маса разработчици, които „пилят“ безполезен код. Те са най-големите губещи, защото изгубеното време не се връща. Такива пирамиди са изключително полезни за Торвалдс и неговите сътрудници. И колкото повече от тези пирамиди, толкова по-добре за тях. За да се захранят такива пирамиди, всичко може да бъде взето в ядрото. Разбира се, в публичното пространство те говорят обратното. Но съдя не по думите, а по делата.
И така, „бъдещето на файловите системи в Linux“ е още един силно рекламиран, но трудно използваем софтуер. След Btrfs, с голяма вероятност, мястото на такова „бъдеще“ ще бъде заето от Bcachefs, което е още един опит за пресичане на блоковия слой на Linux с файлова система (лошият пример е заразен). И което е типично: има същите проблеми като в Btrfs. Дълго време подозирах това и след това някак си не можах да устоя и погледнах в кода - вярно е!
Авторите на Bcachefs и Btrfs, когато създаваха своите FS, активно използваха източници на други хора, разбирайки малко за тях. Ситуацията много напомня на детската игра „развален телефон“. И мога грубо да си представя как този код ще бъде включен в ядрото. Всъщност никой няма да види „греблата“ (по-късно всички ще стъпят върху тях). След многобройни приказки относно стила на кода, обвинения в несъществуващи нарушения и т.н., ще бъде направен извод за „лоялността“ на автора, колко добре той „взаимодейства“ с други разработчици и колко успешно всичко това може след това да бъдат продадени на корпорации.
Крайният резултат няма да заинтересува никого. Преди 20 години може би щях да се интересувам, но сега въпросите са поставени по друг начин: ще бъде ли възможно това да се популяризира, така че определени хора да бъдат наети през следващите десет години. И, уви, не е обичайно да се чудим за крайния резултат.
Като цяло силно бих ви посъветвал да не започвате да преоткривате вашата файлова система от нулата. Защото дори значителни финансови инвестиции няма да са достатъчни, за да получите нещо конкурентно след десет години. Разбира се, говоря за сериозни проекти, а не за тези, които са предназначени да бъдат „бутнати“ в ядрото. Така че по-ефективен начин да изразите себе си е да се включите в реални разработки, като нас. Това, разбира се, не е лесно да се направи - но това е случаят с всеки проект на високо ниво.
Първо, ще трябва самостоятелно да преодолеете проблема, който ще предложа. След което, убеден в сериозността на вашите намерения, ще започна да помагам. Традиционно използваме само собствени разработки. Изключение правят алгоритмите за компресиране и някои хеш функции. Ние не изпращаме разработчици да пътуват до конференции и след това не седим и не комбинираме идеи на други хора („може би какво ще се случи“), както е обичайно в повечето стартиращи компании.
Всички алгоритми разработваме сами. В момента се интересувам от алгебрични и комбинаторни аспекти на науката за съхранение на данни. По-специално, крайни полета, асимптотика, доказателство за неравенства. Има работа и за обикновени програмисти, но трябва да ви предупредя веднага: всички предложения „погледнете друга FS и направете същото“ се игнорират. Пачове, насочени към по-тясна интеграция с Linux чрез VFS, също ще бъдат там.
Така че, ние нямаме рейк, но имаме разбиране накъде трябва да се движим и имаме увереност, че тази посока е правилната. Това разбиране не дойде под формата на манна от небето. Нека ви напомня, че зад гърба си имаме 29 години опит в разработката, две файлови системи, написани от нулата. И същия брой помощни програми за възстановяване на данни. И това е много!
Източник: opennet.ru