Второ интервју со Едуард Шишкин, развивач на Reiser4 FS

Објавено е второто интервју со Едуард Шишкин, развивач на датотечен систем 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 (како „фрагменти“ во дрво или како размери од неформатирани блокови) - крајниот резултат ќе биде ист.

Нема да можете да ги подложите на таков напад други датотечни системи нагоре (без разлика што ќе ви кажат). Одамна ја објаснив причината за проблемот: ова е целосна перверзија на концептот на Б-дрвото во Btrfs, што овозможува негово спонтано или намерно дегенерирање. Особено, при одредени оптоварувања, вашиот датотечен систем постојано ќе се „распаѓа“ за време на работата самостојно, без надворешна помош. Јасно е дека сите видови на „притискање“ процеси во заднина ќе го спасат денот само на поединечни работни површини.

На колективните сервери, напаѓачот секогаш ќе може да ги „понапреди“. Системскиот администратор нема ни да може да утврди кој точно го малтретирал. Најбрзиот начин да се реши овој проблем во Btrfs е да се врати структурата на редовно Б-дрво, т.е. редизајнирање на форматот на дискот и препишување значајни делови од кодот Btrfs. Ова ќе трае 8-10 години, вклучително и дебагирање, под услов програмерите строго да ги следат оригиналните написи за соодветните алгоритми и структури на податоци и да не ја играат играта „скршен телефон“, како што е вообичаено (и охрабрувано) во „Linux“. начин“.

Тука, исто така, треба да го додадеме времето потребно за програмерите да го разберат сето ова. Ова е местото каде што станува потешко. Во секој случај, 10 години не им беа доволни да разберат. Па, дотогаш не можете да се надевате на чудо. Тоа нема да се случи во форма на опција за монтирање „за која јас и ти не знаевме“, или во форма на лепенка што е „само прашање на работа“ да се подготви. За секоја таква избрзана „поправка“ ќе презентирам ново сценарио на дегенерација. Б-дрвата се една од моите омилени теми и морам да кажам дека овие структури не трпат слободи со себе!

Како да ги поставам 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. Се сеќавам дека беше спроведено истражување од овој вид: на некои датотечни системи од возводно, беа создадени огромен број објекти на погони од високата класа од новата генерација. Според резултатите, XFS се однесувал подобро од ext4. Така почнаа да го промовираат како најперспективно. Во секој случај, тука не би барал ништо сензационално.

За мене, тоа е како да го замениле шилото со сапун. Нема смисла да се развиваат ext4 и XFS. И паралелно и кој било од нив да се избере. Ништо добро нема да дојде од ова. Иако, во природата често има ситуации кога има многу потенцијал за раст, но нема простор за растење. Во овој случај, се појавуваат разни бизарно грди нови израстоци, кон кои сите покажуваат со прст („Ох, види, што нема да видиш во овој живот!“).

Дали мислите дека прашањето за прекршување на слојот е решено (во негативна смисла) со доаѓањето на функциите за шифрирање во ext4, F2FS (да не зборуваме за RAID во Btrfs)?

Општо земено, воведувањето на какви било нивоа и донесувањето одлука за нивно неповредување е обично прашање на политика и не се обврзувам да коментирам ништо овде. Објективните аспекти на прекршувањето на слојот се од мал интерес за никого, но можеме да разгледаме некои од нив користејќи го примерот на прекршување „од горе“, имено, имплементацијата во FS на функционалноста што веќе постои на блок слојот. Таквото „прекршување“ е оправдано само со ретки исклучоци. За секој таков случај, прво мора да докажете две работи: дека тоа е навистина потребно и дека дизајнот на системот нема да биде оштетен со тоа.

На пример, пресликувањето, кое традиционално е активност за блок слојот, има смисла да се имплементира на ниво на датотечен систем. Од различни причини. На пример, „тивко“ оштетување на податоците (бит гниење) се јавува на дисковите. Ова е кога уредот работи правилно, но податоците од блокот неочекувано се оштетуваат под влијание на тврд гама квант што го емитува далечен квазар итн. Најлошото нешто е ако овој блок се испостави дека е системски блок FS (суперблок, блок на битмапа, јазол на дрво за складирање итн.), бидејќи тоа сигурно ќе доведе до паника на кернелот.

Ве молиме имајте предвид дека огледалата што ги нуди блок слојот (т.н. RAID 1) нема да ве спасат од овој проблем. Па, навистина: некој треба да ги провери контролните суми и да ја прочита репликата во случај на неуспех? Покрај тоа, има смисла да се пресликуваат не само сè, туку само метаподатоците. Некои важни податоци (на пример, извршни датотеки на критични апликации) може да се складираат како метаподатоци. Во овој случај, тие ги добиваат истите гаранции за безбедност. Има смисла да се довери заштитата на преостанатите податоци на други потсистеми (можеби дури и кориснички апликации) - ги обезбедивме сите потребни услови за ова.

Таквите „економски“ огледала имаат право да постојат и тие можат ефективно да се организираат само на ниво на датотечен систем. Во спротивно, прекршувањето на слоевитоста е натрупување на потсистем со дупликат код заради некои микроскопски придобивки. Впечатлив пример за ова е имплементацијата на RAID-5 користејќи FS. Ваквите решенија (сопствен RAID / LVM во датотечен систем) го убиваат вториот во архитектонска смисла. Овде, исто така, треба да се забележи дека прекршувањето на слоевитоста е „ставено во тек“ од разни видови маркетинг измамници. Во отсуство на какви било идеи, функционалноста која долго време е имплементирана на соседните нивоа се додава на потсистемите, ова е претставено како нова исклучително корисна карактеристика и активно се турка.

Reiser4 беше обвинет за кршење на нивоата „одоздола“. Врз основа на фактот дека датотечниот систем не е монолитен, како и сите други, туку модуларен, беше направена неоснована претпоставка дека го прави она што треба да го направи нивото погоре (VFS).

Дали е можно да се зборува за смртта на ReiserFS v3.6 и, на пример, JFS? Во последно време речиси и да не добиваат внимание во сржта. Дали се застарени?

Тука треба да дефинираме што значи смртта на софтверски производ. Од една страна, тие успешно се користат (на крајот на краиштата, за тоа се создадени), што значи дека живеат. Од друга страна, не можам да зборувам за JFS (не знам многу), но ReiserFS (v3) е многу тешко да се прилагоди на новите трендови (тестиран во пракса). Ова значи дека во иднина програмерите ќе обрнат внимание не на тоа, туку на оние што полесно се прилагодуваат. Од оваа страна излегува дека, за жал, архитектонски е мртов. Воопшто не би манипулирал со концептот „морално застарен“. Добро се однесува, на пример, за гардероба, но не и за софтверски производи. Постои концепт на инфериорност и супериорност во нешто. Апсолутно можам да кажам дека ReserFS v3 сега е инфериорен во однос на Reiser4 во сè, но во некои типови на оптоварување е супериорен во однос на сите други upstream FS.

Дали знаете за развојот на FS Tux3 и HAMMER/HAMMER2 (FS за DragonFly BSD)?

Да, знаеме. Во Tux3 еднаш бев заинтересиран за технологијата на нивните снимки (т.н. „покажувачи на верзијата“), но во Reiser4 најверојатно ќе одиме по друг пат. Долго време размислував да поддржам снимки и сè уште не сум одлучил како да ги имплементирам за едноставни томови на Reiser4. Факт е дека новоформираната „мрзлива“ референтна техника предложена од Охад Родех работи само за Б-дрвата. Ние ги немаме. За оние структури на податоци што се користат во Reiesr4, „мрзливите“ бројачи не се дефинирани - за да се воведат, неопходно е да се решат одредени алгоритамски проблеми, кои сè уште никој не ги презел.

Според ЧЕКАН: Читав статија од креаторот. Не се заинтересирани. Повторно, Б-дрва. Оваа структура на податоци е безнадежно застарена. Го напуштивме во минатиот век.

Како ја оценувате растечката побарувачка за мрежни кластери FS како CephFS/GlusterFS/итн? Дали ова барање значи поместување на приоритетите на програмерите кон мрежните FS и недоволно внимание на локалните FS?

Да, дојде до такво поместување на приоритетите. Развојот на локални датотечни системи стагнира. За жал, да се направи нешто значајно за локални количини сега е доста тешко и не секој може да го направи тоа. Никој не сака да инвестира во нивниот развој. Ова е исто како да барате од комерцијална организација да одвои пари за математичко истражување - без никаков ентузијазам ќе ве прашаат како можете да заработите пари на нова теорема. Сега локален FS е нешто што магично се појавува „надвор од кутијата“ и „секогаш треба да работи“, а ако не функционира, предизвикува неоправдано негодување како: „Да, што мислат тие!“

Оттука и недостатокот на внимание на локалните ФС, иако има уште многу работа во таа област. И да, сите се свртеа кон дистрибуираното складирање, кое е изградено врз основа на веќе постоечки локални датотечни системи. Сега е многу модерно. Фразата „Големи податоци“ предизвикува наплив на адреналин кај многумина, поврзувајќи ја со конференции, работилници, големи плати итн.

Колку е во принцип разумно да се имплементира мрежниот датотечен систем во просторот на јадрото наместо во корисничкиот простор?

Многу разумен пристап кој сè уште никаде не е имплементиран. Општо земено, прашањето во кој простор треба да се имплементира мрежен датотечен систем е „меч со две острици“. Па, ајде да погледнеме на пример. Клиентот снимал податоци на оддалечена машина. Тие паднаа во кешот на нејзината страница во форма на валкани страници. Ова е работа за мрежен датотечен систем „тенка порта“ во просторот на јадрото. Тогаш оперативниот систем порано или подоцна ќе побара од вас да ги напишете тие страници на дискот за да ги ослободите. Потоа стапува во игра модулот за IO-препраќање (испраќање) FS мрежа. Тоа одредува на која машина на сервер (серверски јазол) ќе одат овие страници.

Тогаш мрежниот стек го презема (и, како што знаеме, се имплементира во просторот на јадрото). Следно, јазолот на серверот го прима тој пакет со податоци или метаподатоци и му дава инструкции на модулот за складирање на заднината (т.е. локалниот FS што работи во просторот на јадрото) да ги сними сите овие работи. Значи, го сведевме прашањето до каде треба да работат модулите „испраќање“ и „примање“. Ако некој од тие модули работи во корисничкиот простор, тоа неизбежно ќе доведе до префрлување на контекстот (поради потребата да се користат услуги на јадрото). Бројот на такви прекинувачи зависи од деталите за имплементацијата.

Ако има многу такви прекинувачи, тогаш пропусната моќ на складирање (изведба на I/O) ќе се намали. Ако вашето складирање на задниот дел се состои од бавни дискови, тогаш нема да забележите значителен пад. Но, ако имате брзи дискови (SSD, NVRAM, итн.), тогаш префрлувањето на контекстот веќе станува „тесно грло“ и, со заштеда на префрлување контекст, перформансите може значително да се зголемат. Стандардниот начин да заштедите пари е да ги преместите модулите во просторот на јадрото. На пример, откривме дека преместувањето на серверот 9p од QEMU до кернелот на машината домаќин доведува до трикратно зголемување на перформансите на VirtFS.

Ова, се разбира, не е мрежен FS, но целосно ја одразува суштината на нештата. Негативната страна на оваа оптимизација се проблемите со преносливоста. За некои, второто може да биде критично. На пример, GlusterFS воопшто нема модули во кернелот. Благодарение на ова, сега работи на многу платформи, вклучувајќи го и NetBSD.

Кои концепти би можеле да ги позајмат локалните FS од мрежните и обратно?

Во денешно време, мрежните FS, како по правило, имаат додатоци преку локалните FS, така што не разбирам како можете да позајмите нешто од второто. Па, навистина, да размислиме за компанија од 4 вработени, во која секој си го прави своето: едниот дистрибуира, другиот испраќа, третиот прима, четвртиот складира. А, прашањето што може да позајми компанијата од својот вработен кој ја складира, звучи некако неточно (веќе го има она што можеше да го позајми од него долго време).

Но, локалните FS имаат многу да научат од мрежните. Прво, треба да научите од нив како да ги соберете логичките волумени на високо ниво. Сега т.н „Напредните“ локални датотечни системи собираат логички волумени исклучиво користејќи технологија „виртуелен уред“ позајмена од LVM (истото заразно прекршување на слоевитоста што првпат беше имплементирано во ZFS). Со други зборови, преводот на виртуелните адреси (броеви на блок) во реални и назад се случува на ниско ниво (т.е. откако датотечниот систем ќе издаде барање за влез/излез).

Ве молиме имајте предвид дека додавањето и отстранувањето уреди на логички волумени (не огледала) распоредени на блок слојот доведува до проблеми за кои добавувачите на таквите „функционалности“ скромно молчат. Зборувам за фрагментација на реални уреди, која може да достигне монструозни вредности, додека на виртуелен уред се е во ред. Сепак, малку луѓе се заинтересирани за виртуелни уреди: сите се заинтересирани за тоа што се случува на вашите вистински уреди. Но, FS слични на ZFS (како и сите FS во врска со LVM) работат само со уреди со виртуелен диск (одделете ги адресите на виртуелните дискови од слободните, дефрагментирајте ги овие виртуелни уреди итн.). И тие немаат поим што се случува на вистински уреди!

Сега замислете дека имате нула фрагментација на виртуелниот уред (односно, имате само една огромна големина што живее таму), додавате диск на вашиот логичен волумен, а потоа отстранувате друг случаен диск од вашиот логичен волумен и потоа правите ребаланс. И толку пати. Не е тешко да се замисли дека на виртуелниот уред сè уште ќе го живеете истиот обем, но на вистинските уреди нема да видите ништо добро.

Најлошото е што не сте ни во можност да ја поправите оваа ситуација! Единственото нешто што можете да направите овде е да побарате од датотечниот систем да го дефрагментира виртуелниот уред. Но, таа ќе ви каже дека таму сè е супер - има само една мерка, фрагментацијата е нула, а не може да биде подобро! Значи, логичките волумени распоредени на ниво на блок не се наменети за повторено додавање/отстранување на уреди. На добар начин, треба само еднаш да соберете логичен волумен на ниво на блок, да го дадете на датотечниот систем и потоа да не правите ништо друго со него.

Дополнително, комбинацијата на независни подсистеми FS+LVM не дозволува да се земе предвид различната природа на погоните од кои се собираат логички волумени. Навистина, да претпоставиме дека сте собрале логичен волумен од HDD и уреди со цврста состојба. Но, тогаш првото ќе бара дефрагментација, а второто не. За второто, треба да издадете барања за отфрлање, но за првото, не, итн. Сепак, во оваа комбинација е доста тешко да се покаже таква селективност.

Забележете дека откако ќе создадете сопствен LVM на датотечниот систем, ситуацијата не се подобрува многу. Згора на тоа, со тоа всушност ставате крај на изгледите дека некогаш ќе го подобрите во иднина. Ова е многу лошо. Различни типови на погони можат да живеат на иста машина. И ако датотечниот систем не прави разлика меѓу нив, тогаш кој ќе направи?

Друг проблем се чека за т.н. Датотечни системи „Write-Anywhere“ (ова го вклучува и Reiser4, ако сте го навеле соодветниот трансакциски модел за време на монтирањето). Таквите датотечни системи мора да обезбедат алатки за дефрагментација кои се без преседан во нивната моќ. И менаџерот за јачина на звук на ниско ниво не помага овде, туку само се попречува. Факт е дека со таков менаџер, вашиот FS ќе складира карта на бесплатни блокови на само еден уред - виртуелен. Според тоа, можете само да дефрагментирате виртуелен уред. Ова значи дека вашиот дефрагментатор ќе работи долго, долго на огромен простор со виртуелни адреси.

И ако имате многу корисници кои прават случајни презапишувања, тогаш корисниот ефект на таков дефрагментатор ќе се сведе на нула. Вашиот систем неизбежно ќе почне да успорува и ќе треба само да ги свиткате рацете пред разочарувачката дијагноза „скршен дизајн“. Неколку дефрагментатори кои работат на истиот адресен простор само ќе се мешаат еден со друг. Сосема поинаква работа е ако одржувате сопствена мапа на бесплатни блокови за секој вистински уред. Ова ефикасно ќе го паралелизира процесот на дефрагментација.

Но, ова може да се направи само ако имате менаџер за логички волумен на високо ниво. Локалните датотечни системи со такви менаџери претходно не постоеле (барем, не знам за нив). Само мрежни датотечни системи (на пример GlusterFS) имаа такви менаџери. Друг многу важен пример е алатката за проверка на интегритетот на јачината на звукот (fsck). Ако складирате сопствена независна мапа на слободни блокови за секој подтом, тогаш постапката за проверка на логичен волумен може ефективно да се паралелизира. Со други зборови, логичните волумени со менаџери на високо ниво се зголемуваат подобро.

Покрај тоа, со менаџерите за јачина на звук на ниско ниво нема да можете да организирате целосни снимки. Со датотечен систем слични на LVM и ZFS, можете да правите само локални снимки, но не и глобални снимки. Локалните снимки ви дозволуваат веднаш да ги вратите назад само редовните операции со датотеки. И никој таму нема да ги врати операциите со логички волумени (додавање/отстранување уреди). Да го погледнеме ова со пример. Во одреден момент во времето, кога имате логичен волумен од два уреди А и Б кои содржат 100 датотеки, правите слика од системот S и потоа креирате уште стотина датотеки.

После тоа, го додавате уредот C на вашата јачина на звук и на крајот го враќате системот на снимката S. Прашање: Колку датотеки и уреди содржи вашиот логичен волумен по враќањето во S? Ќе има 100 датотеки, како што можеби претпоставувате, но ќе има 3 уреди - тоа се истите уреди A, B и C, иако во моментот кога беше креирана снимката имаше само два уреди во системот (А и Б ). Операцијата за додавање уред C не се врати назад, и ако сега го отстраните уредот C од компјутерот, тој ќе ги оштети вашите податоци, така што пред да го избришете ќе треба прво да извршите скапа операција за да го отстраните уредот од логичкиот волумен за ребаланс, што ќе ги распрсне сите податоци од уредот C на уредите A и B. Но, ако вашиот FS поддржува глобални снимки, таквото ребалансирање нема да биде потребно и по моменталното враќање на S, можете безбедно да го отстраните уредот C од компјутерот.

Значи, глобалните снимки се добри затоа што ви овозможуваат да избегнете скапо отстранување (додавање) на уред од логичен волумен (во логичен волумен) со голема количина на податоци (се разбира, ако се сеќавате да го „снимите“ вашиот систем во вистинско време). Дозволете ми да ве потсетам дека создавањето снимки и враќањето на датотечниот систем на нив се моментални операции. Може да се појави прашањето: како е воопшто можно веднаш да ја вратите операцијата на логичен волумен што ви траеше три дена? Но, тоа е можно! Под услов вашиот датотечен систем да е правилно дизајниран. Дојдов до идеја за вакви „3Д снимки“ пред три години, а минатата година ја патентирав оваа техника.

Следното нешто што локалните 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-и) значи фундаментално нови предизвици за дизајнот на датотечниот систем?

Да. И ова се нормални стимулации за развој на ФС. Предизвиците можат да бидат различни и сосема неочекувани. На пример, имам слушнато за дискови каде што брзината на операцијата В/И е многу зависна од големината на податокот и неговото поместување. Во Linux, каде што големината на блокот FS не може да ја надмине големината на страницата, таков диск нема да ги прикаже своите целосни способности стандардно. Меѓутоа, ако вашиот датотечен систем е дизајниран правилно, тогаш постои шанса да извлечете многу повеќе од него.

Колку луѓе во моментов работат со кодот Reiser4 освен вас?

Помалку отколку што би сакал, но и јас не доживувам сериозен недостиг на ресурси. Повеќе од задоволен сум од темпото на развој на Reiser4. Нема да „возам коњи“ - ова не е вистинската област. Еве, „ако возиш потивко, ќе продолжиш!“ Современиот датотечен систем е најкомплексниот потсистем на јадрото, чии погрешни решенија за дизајн можат да ги поништат следните години човечка работа.

Нудејќи волонтери да спроведат нешто, секогаш гарантирам дека напорите сигурно ќе доведат до правилен резултат, кој може да биде баран за сериозни потреби. Како што разбирате, не може да има многу такви гаранции одеднаш. Во исто време, не можам да поднесам „фигури“ кои бесрамно промовираат „карактеристики“ на очигледно неупотребливиот софтвер, измамувајќи стотици корисници и програмери, а во исто време седат и се смеат на самитите на кернелот.

Дали некоја компанија изрази подготвеност да го поддржи развојот на Reiser4?

Да, имаше такви предлози, вкл. и од голем продавач. Но, за ова морав да се преселам во друга земја. За жал, веќе немам 30 години, не можам да се отцепам и да заминам така на првиот свиреж.

Кои карактеристики во моментов недостасуваат на Reiser4?

Не постои функција „промена на големина“ за едноставни томови, слична на онаа што се наоѓа во ReiserFS(v3). Дополнително, операциите со датотеки со знаменцето DIRECT_IO нема да наштетат. Следно, би сакал да можам да издвојам том во „семантички подтомови“, кои немаат фиксна големина и кои можат да се монтираат како независни томови. Овие проблеми се добри за почетници кои сакаат да се обидат во „вистинската работа“.

И, конечно, би сакал да имам мрежни логички волумени со едноставна имплементација и администрација (современите алгоритми веќе го дозволуваат тоа). Но, она што Reiser4 дефинитивно никогаш нема да го има е RAID-Z, скрабови, кешови на слободен простор, 128-битни променливи и други маркетиншки глупости што се појавија на позадината на недостигот на идеи кај развивачите на некои датотечни системи.

Може ли сè што може да биде потребно да се имплементира со приклучоци?

Ако зборуваме само во однос на интерфејси и приклучоци (модули) кои ги имплементираат, тогаш не сè. Но, ако воведете и врски на овие интерфејси, тогаш, меѓу другото, ќе ги имате концептите на повисоки полиморфизми, со кои веќе можете да се справите. Замислете дека хипотетички сте замрзнале објектно-ориентиран систем за извршување, ја смениле вредноста на покажувачот на инструкции за да укаже на друг додаток кој го имплементира истиот интерфејс X, а потоа го одмрзнавте системот за да продолжи да се извршува.

Ако крајниот корисник не забележи таква „замена“, тогаш велиме дека системот има полиморфизам од нула ред во интерфејсот X (или системот е хетероген во интерфејсот X, што е истото). Ако сега не само што имате збир на интерфејси, туку имате и врски на нив (график на интерфејс), тогаш можете да воведете полиморфизми од повисоки редови, што ќе ја карактеризира хетерогеноста на системот веќе во „соседството“ на кој било интерфејс. Одамна воведов таква класификација, но, за жал, никогаш не се случи.

Значи, со помош на приклучоци и такви повисоки полиморфизми, можете да опишете која било позната карактеристика, како и да ги „предвидите“ оние што никогаш не биле ни спомнати. Не успеав строго да го докажам ова, но сè уште не знам за контрапример. Во принцип, ова прашање ме потсети на „Програмата Ерланген“ на Феликс Клајн. Едно време тој се обидел да ја претстави целата геометрија како гранка на алгебрата (конкретно, групна теорија).

Сега на главното прашање - како одат работите со промоцијата на Reiser4 во главното јадро? Имаше ли публикации за архитектурата на овој датотечен систем за кои зборувавте во последното интервју? Колку е ова прашање релевантно од ваша гледна точка?

Генерално, три години бараме вклучување во главната гранка. Последниот коментар на Рајзер во јавната тема каде беше поднесено барањето за повлекување остана неодговорен. Значи, сите дополнителни прашања не се за нас. Јас лично не разбирам зошто треба да се „спојуваме“ во одреден оперативен систем. На Linux, светлината не се спојуваше како клин. Значи, постои посебно складиште во кое ќе има неколку филијали-порти за различни ОС. На кој му треба може да ја клонира соодветната порта и да прави што сака со неа (се разбира во рамките на лиценцата). Па, ако некому не му треба, тогаш тоа не е мој проблем. Во овој момент, предлагам да се разгледа прашањето за „промоција во главниот кернел на Линукс“ како решено.

Публикациите за архитектурата на FS се релевантни, но досега најдов само време за моите нови резултати, кои ги сметам за поголем приоритет. Друга работа е што јас сум математичар, а во математиката секоја публикација е резиме на теореми и нивните докази. Објавувањето што било таму без доказ е знак на лош вкус. Ако темелно докажам или отфрлам каква било изјава за архитектурата на FS, тогаш резултатот ќе биде такви купови што ќе биде доста тешко да се помине. На кого му треба? Веројатно затоа сè останува во старата форма - изворниот код и коментарите на него.

Што има ново во Reiser4 во изминатите неколку години?

Долгоочекуваната стабилност конечно се оствари. Еден од последните што се појави беше бубачка што доведе до „неизбришливи“ директориуми. Тешкотијата беше што се појавуваше само на позадината на судирите на хашот на имињата и со одредена локација на записите на директориумот во јазол на дрво. Сепак, сè уште не можам да го препорачам Reiser4 за производство: за ова треба да направите одредена работа со активна интеракција со администраторите на системот за производство.

Конечно успеавме да ја спроведеме нашата долгогодишна идеја - различни модели на трансакции. Претходно, Reiser4 имаше само еден хардкодиран модел Macdonald-Reiser. Ова создаде проблеми во дизајнот. Конкретно, снимките не се можни во таков трансакциски модел - тие ќе бидат оштетени од атомска компонента наречена „ПРЕПИШИ СЕТ“. Reiser4 моментално поддржува три модели на трансакции. Во еден од нив (Write-Anywhere), атомската компонента OVERWRITE SET вклучува само системски страници (слики од битмапи на дискот, итн.), кои не можат да се „фотографираат“ (проблемот со пилешко и јајце).

Така, сликите сега можат да се реализираат на најдобар можен начин. Во друг трансакциски модел, сите модифицирани страници одат само во КОМПЈЕТО ЗА ПРЕПИШУВАЊЕ (односно, во суштина тоа е чисто журналирање). Овој модел е за оние кои се пожалија на брзата фрагментација на партициите на Reiser4. Сега во овој модел вашата партиција ќе се фрагментира не побрзо отколку со ReiserFS (v3). Сите три постоечки модели, со одредени резерви, ја гарантираат атомичноста на операциите, но моделите со губење на атомичноста и зачувување само на интегритетот на делот исто така можат да бидат корисни. Таквите модели можат да бидат корисни за сите видови апликации (бази на податоци итн.), кои веќе имаат преземено некои од овие функции. Многу е лесно да се додадат овие модели на Reiser4, но јас не го направив тоа, бидејќи никој не ме праша, а мене лично не ми треба.

Се појавија контролни суми на метаподатоци и неодамна ги дополнив со „економични“ огледала“ (сеуште нестабилен материјал). Ако контролната сума на кој било блок не успее, Reiser4 веднаш го чита соодветниот блок од уредот со реплика. Забележете дека ZFS и Btrfs не можат да го направат тоа: дизајнот не го дозволува тоа. Таму мора да извршите посебен процес на скенирање на заднина наречен „прочистување“ и да чекате да дојде до проблематичниот блок. Програмерите фигуративно ги нарекуваат таквите настани „патерици“.

И конечно, се појавија хетерогени логички волумени, кои нудат сè што ZFS, Btrfs, блок слојот, како и комбинациите 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. Патем: она што навистина ми се допаѓа во нивната заедница е тоа што таму одлуките ги носи ажуриран совет од независни експерти, што нема никаква врска со владината измама на едно постојано лице.

Како ја оценувате корисничката заедница на Линукс денес? Дали стана повеќе „поп“?

Со оглед на природата на мојата работа, доста ми е тешко да го проценам ова. Претежно корисници доаѓаат кај мене со извештаи за грешки и барања за поправка на делот. Корисниците како корисници. Некои се поупатени, некои помалку. Сите се третираат исто. Па, ако корисникот ги игнорира моите инструкции, тогаш извинете ме: наредбата за игнорирање ќе биде внесена и од моја страна.

Дали е можно да се предвиди развојот на датотечните системи за следните пет до десет години? Што мислите, кои се главните предизвици со кои може да се соочат развивачите на FS?

Да, не е тешко да се направи таква прогноза. Долго време нема развој на датотечни системи во upstream. Се создава само изгледот на таквите. Програмерите на локални датотечни системи наидоа на проблеми поврзани со лошиот дизајн. Тука треба да се направи предупредување. Таканареченото „складирање“, „лижење“ и пренесување на кодот не го сметам за развој и развој. И не го класифицирам недоразбирањето наречено „Бтрфс“ како развој од причините што веќе ги објаснив.

Секој лепенка само ги влошува неговите проблеми. Па. и секогаш има разни видови „евангелисти“ за кои „сè функционира“. Во основа, тоа се ученици и студенти кои прескокнуваат предавања. Замислете: тоа функционира за него, но професорот не. Каков адреналин е ова! Од моја гледна точка, најголема штета предизвикуваат „занаетчиите“ кои побрзаа со ентузијазам да ги „завртат“ прекрасните карактеристики на Btrfs на секакви слоеви како systemd, docker итн. - ова веќе наликува на метастази.

Ајде сега да се обидеме да направиме прогноза за пет до десет години. Веќе накратко наведов што ќе правиме во Reiser4. Главниот предизвик за локалните развивачи на FS од возводно ќе биде (да, веќе стана) неможноста да се направи пристојна работа за плата. Без никакви идеи во областа на складирање податоци, тие ќе продолжат да се обидуваат да ги закрпат овие несреќни VFS, XFS и ext4. Состојбата со VFS изгледа особено комично на оваа позадина, потсетувајќи на лудото модернизирање на ресторан во кој нема готвачи, а не се очекуваат готвачи.

Сега VFS-кодот, без никакви услови, заклучува неколку мемориски страници во исто време и го поканува основниот FS да работи на нив. Ова беше воведено за да се подобрат перформансите на Ext4 при операциите за бришење, но како што е лесно да се разбере, таквото истовремено заклучување е целосно некомпатибилно со напредните модели на трансакции. Односно, нема да можете едноставно да додадете поддршка за некој паметен датотечен систем во кернелот. Не знам каква е ситуацијата во другите области на Linux, но што се однесува до датотечните системи, секој развој овде веројатно нема да биде компатибилен со политиката што ја спроведува Торвалдс во пракса (академските проекти се исфрлени, а измамниците кои немаат поим какво Б-дрво, се издаваат бескрајни кредити на доверба). Затоа, беше поставен курс за бавно распаѓање. Се разбира, тие ќе се обидат со сите сили да го пренесат тоа како „развој“.

Понатаму, „чуварите“ на датотечните системи, сфаќајќи дека нема да заработите многу само од „складирање“, ќе се обидат во попрофитабилен бизнис. Овие се, по правило, дистрибуирани датотечни системи и виртуелизација. Можеби ќе го пренесат модерниот ZFS некаде на друго место каде што сè уште не постои. Но, тоа, како и сите FS од возводно, наликува на новогодишна елка: ако можете да закачите некои други мали нешта на врвот, тогаш не можете да навлезете подлабоко. Признавам дека е можно да се изгради сериозен систем за претпријатија базиран на ZFS, но бидејќи сега разговараме за иднината, можам само со тага да констатирам дека ZFS е безнадежен во овој поглед: со нивните виртуелни уреди, момците го прекинаа кислородот за себе и за идните генерации за понатамошен развој. ЗФС е минато. А ext4 и XFS не се ни завчера.

Вреди да се спомене посебно за сензационалниот концепт на „Линукс датотечен систем од следната генерација“. Ова е целосно политички и маркетиншки проект создаден за можност, така да се каже, да се „закачи иднината на датотечните системи“ во Linux зад одредени знаци. Факт е дека Linux порано беше „само за забава“. Но, сега тоа е првенствено машина за правење пари. Тие се направени на се што е можно. На пример, многу е тешко да се создаде добар софтверски производ, но паметните „програмери“ одамна сфатија дека нема потреба воопшто да се напрегаат: можете успешно да продадете непостоечки софтвер што беше најавен и промовиран на секакви јавни настани - главната работа е што слајдовите за презентација треба да содржат повеќе „функционалности“.

Датотечните системи се совршени за ова, бидејќи можете безбедно да се пазарите десет години за резултатот. Па, ако некој подоцна се жали за недостатокот на овој резултат, тогаш тој едноставно не разбира ништо за датотечните системи! Ова потсетува на финансиска пирамида: на врвот се авантуристите кои го започнаа овој хаос, и оние малкумина кои имаа „среќа“: тие „повлекоа дивиденди“, т.е. добил пари за развој, добил добро платена работа како менаџери, се „појавувал“ на конференции итн.

Следуваат оние кои се „несреќни“: ќе бројат загуби, ќе се справат со последиците од примената на неупотреблив софтверски производ во производството, „итн. Има многу повеќе од нив. Па, во основата на пирамидата има огромна маса на програмери кои „пилаат“ бескорисен код. Тие се најголемите губитници, бидејќи потрошеното време не може да се врати. Таквите пирамиди се исклучително корисни за Торвалдс и неговите соработници. И колку повеќе од овие пирамиди, толку подобро за нив. За да се нахранат таквите пирамиди, сè може да се внесе во јадрото. Се разбира, во јавноста го кажуваат спротивното. Но, јас не судам со зборови туку со дела.

Значи, „иднината на датотечните системи во Linux“ е уште еден високо промовиран, но тешко употреблив софтвер. По Btrfs, со голема веројатност, местото на таквата „иднина“ ќе го заземе Bcachefs, што е уште еден обид да се премине блок слојот на Linux со датотечен систем (лошиот пример е заразен). И што е типично: има исти проблеми како во Btrfs. Се сомневав во ова долго време, а потоа некако не можев да одолеам и го погледнав кодот - вистина е!

Авторите на Bcachefs и Btrfs, при креирањето на нивните FS, активно користеле туѓи извори, разбирајќи малку за нив. Ситуацијата многу потсетува на детската игра „расипан телефон“. И приближно можам да замислам како овој код ќе биде вклучен во кернелот. Всушност, никој нема да ги види „греблата“ (сите ќе ги згазат подоцна). По многубројните препирки за стилот на кодот, обвинувањата за непостоечки прекршувања итн., ќе се донесе заклучок за „лојалноста“ на авторот, колку добро „интеракција“ со другите програмери и колку успешно може сето тоа потоа се продаваат на корпорации.

Крајниот резултат нема да заинтересира никого. Пред 20 години, можеби, ќе ме интересираше, но сега прашањата се поставуваат поинаку: дали ќе може да се промовира ова за да се вработат одредени луѓе во следните десет години. И, за жал, не е вообичаено да се прашуваме за крајниот резултат.

Во принцип, силно би ве советувал да не започнете повторно да го измислувате вашиот датотечен систем од нула. Затоа што ниту значајните финансиски инвестиции нема да бидат доволни за да се добие нешто конкурентно за десет години. Се разбира, зборувам за сериозни проекти, а не за оние што се наменети да се „турнат“ во јадрото. Значи, поефективен начин да се изразите е да се придружите на вистинските случувања, како нас. Ова, се разбира, не е лесно да се направи - но ова е случај со секој проект на високо ниво.

Прво, ќе треба самостојно да го надминете проблемот што ќе го понудам. После тоа, убеден во сериозноста на вашите намери, ќе почнам да помагам. Традиционално, ние ги користиме само нашите сопствени случувања. Исклучоците се алгоритми за компресија и некои хаш функции. Не ги испраќаме програмерите да патуваат на конференции, а потоа не седиме и не комбинираме туѓи идеи („можеби што ќе се случи“), како што е вообичаено кај повеќето стартапи.

Ние самите ги развиваме сите алгоритми. Во моментов сум заинтересиран за алгебарските и комбинаторните аспекти на науката за складирање податоци. Конкретно, конечни полиња, асимптотика, доказ за нееднаквости. Работа има и за обичните програмери, но морам веднаш да ве предупредам: сите предлози „да погледнете друг FS и да го сторите истото“ се игнорираат. Таму ќе одат и закрпи насочени кон поблиска интеграција со Linux преку VFS.

Значи, немаме гребло, но имаме разбирање за тоа каде треба да се движиме и имаме доверба дека оваа насока е вистинската. Ова разбирање не дојде во форма на мана од небото. Да ве потсетам дека зад нас имаме 29 години развојно искуство, два датотечни системи напишани од нула. И ист број на комунални услуги за обновување податоци. И ова е многу!

Извор: opennet.ru