Druhý rozhovor s Eduardem Shishkinem, vývojářem Reiser4 FS

Byl zveřejněn druhý rozhovor s Eduardem Shishkinem, vývojářem souborového systému Reiser4.

Pro začátek prosím připomeňte čtenářům, kde a pro koho pracujete.

Pracuji jako hlavní architekt úložiště v Huawei Technologies, německém výzkumném centru. V oddělení virtualizace se zabývám různými aspekty ukládání dat. Moje aktivity nesouvisí s konkrétním operačním systémem.

V současnosti se zavazujete k hlavní větvi jádra?

Velmi zřídka, a pouze pokud to můj zaměstnavatel vyžaduje. Naposledy asi před třemi lety jsem posílal záplaty pro zvýšení propustnosti úložiště sdíleného na hostitelích pomocí protokolu 9p (jiný název pro tento podnik je VirtFS). Zde je třeba udělat jednu důležitou poznámku: ačkoli pracuji s Linuxem dlouho, nikdy jsem nebyl jeho fanouškem, to znamená, že „dýchám rovnoměrně“, jako se vším ostatním. Zejména pokud si všimnu nějaké vady, mohu na ni upozornit maximálně jednou. A abyste pak mohli někoho následovat a přesvědčovat - to se nestane.

Pamatuji si, že minule, před deseti lety, jsi byl docela kritický ke stylu vývoje jádra. Změnilo se něco z vašeho (nebo možná korporátního) pohledu, stala se komunita vstřícnější nebo ne? Pokud ne, kdo za to podle vás nese vinu?

Nikdy jsem neviděl žádné změny k lepšímu. Hlavním problémem komunity je nahrazování vědy politickými technologiemi, osobní vztahy, většinový názor, populismus, rady „vnitřních hlasů“, prohnilé kompromisy, všechno kromě vědy. Počítačová věda, ať už se dá říci cokoli, je především exaktní věda. A pokud někdo začne hlásat svou vlastní hodnotu pro 2x2, odlišnou od 4, pod vlajkou „Linux way“ nebo pod nějakou jinou vlajkou, pak to pravděpodobně nepřinese něco jiného než škodu.

Všechny potíže jsou primárně způsobeny neschopností a nedostatečným vzděláním těch, kteří rozhodují. Pokud je manažer nekompetentní, není schopen objektivního, adekvátního rozhodnutí. Pokud je navíc nekulturní, není schopen najít kompetentního odborníka, který by mu správně poradil. S vysokou pravděpodobností padne volba na podvodníka, který říká „zdánlivě správné věci“. Kolem neschopných osamělých vůdců se vždy rozvíjí korupční prostředí. Navíc historie v tomto ohledu nezná výjimky a komunita je toho nejjasnějším potvrzením.

Jak hodnotíte pokrok ve vývoji Btrfs? Zbavila se tato FS dětských nemocí? Jak ho umístíte pro sebe – jako FS „na doma“ nebo i pro firemní použití?

Nezbavil jsem se toho. Vše, co jsem zmínil před 11 lety, je aktuální i dnes. Jedním z problémů s Btrfs, který jej činí nevhodným pro vážné potřeby, je problém volného místa. To ani nemluvím o tom, že je uživatel požádán, aby si zaběhl do obchodu pro nový disk v situacích, kdy by jakýkoli jiný FS ukazoval spoustu volného místa na oddílu. Nemožnost dokončit operaci na logickém svazku kvůli nedostatku volného místa také není to nejhorší. Nejhorší je, že neprivilegovaný uživatel může téměř vždy obejít jakékoli diskové kvóty a připravit všechny o volné místo v poměrně krátkém čase.

Vypadá to takto (testováno pro linuxové jádro 5.12). Na čerstvě nainstalovaném systému se spustí skript, který ve smyčce vytvoří soubory s určitými názvy v domovském adresáři, zapíše do nich data s určitými posuny a poté tyto soubory odstraní. Po minutě spuštění tohoto skriptu se nestane nic neobvyklého. Po pěti minutách se podíl obsazeného místa na oddílu mírně zvětší. Po dvou až třech hodinách dosáhne 50 % (s počáteční hodnotou 15 %). A po pěti nebo šesti hodinách práce se skript zhroutí s chybou „na oddílu není volné místo“. Poté již nebudete moci na svůj oddíl zapsat ani soubor 4K.

Nastává zajímavá situace: nakonec jste do oddílu nic nezapsali a veškeré volné místo (asi 85 %) někam zmizelo. Analýza úseku vystaveného takovému útoku odhalí mnoho uzlů stromu obsahujících pouze jednu položku (objekt vybavený klíčem) o velikosti několika bajtů. To znamená, že obsah, který dříve zabíral 15 % místa na disku, se ukázal být rovnoměrně „rozmazaný“ po celém oddílu, takže není kam zapisovat nový soubor, protože jeho klíč je větší než všechny stávající a volný bloky na oddílu došly.

To vše se navíc děje již na základní konfiguraci Btrfs (bez jakýchkoliv snapshotů, podsvazků atd.) a je jedno, jak se rozhodnete uložit těla souborů do toho FS (jako „fragmenty“ ve stromu nebo jako rozsahy neformátovaných bloků) - konečný výsledek bude stejný.

Takovému útoku nebudete moci vystavit jiné upstream souborové systémy (bez ohledu na to, co vám říkají). Příčinu problému jsem vysvětlil již dávno: jedná se o úplnou zvrácenost konceptu B-stromu v Btrfs, který umožňuje jeho spontánní nebo záměrnou degeneraci. Zejména při určité zátěži se váš souborový systém bude během provozu neustále „rozpadat“ sám, bez cizí pomoci. Je jasné, že všelijaké procesy „lisování“ na pozadí zachrání den pouze na jednotlivých desktopech.

Na kolektivních serverech je útočník vždy bude moci „předběhnout“. Správce systému ani nebude schopen určit, kdo přesně ho šikanoval. Nejrychlejším způsobem, jak tento problém v Btrfs vyřešit, je obnovit strukturu běžného B-stromu, tzn. přepracování formátu disku a přepsání významných částí kódu Btrfs. To bude trvat 8–10 let, včetně ladění, za předpokladu, že vývojáři striktně dodržovali původní články o příslušných algoritmech a datových strukturách a nehráli hru „rozbitého telefonu“, jak je obvyklé (a doporučované) v „Linuxu“. cesta".

Zde je také potřeba připočíst čas potřebný k tomu, aby tomu všemu vývojáři porozuměli. Tady je to složitější. Každopádně 10 let bylo málo, aby pochopili. No, do té doby nemůžete doufat v zázrak. Nestane se to ve formě montážní možnosti, „o které jsme vy ani já nevěděli“, nebo ve formě opravy, kterou je třeba připravit „jen obchodní záležitostí“. Pro každou takovou unáhlenou „opravu“ představím nový scénář degenerace. B-stromy jsou jedním z mých oblíbených témat a musím říct, že tyto struktury netolerují svobody samy se sebou!

Jak umím Btrfs pro sebe? Jako něco, co se absolutně nedá nazvat souborovým systémem, natož použít. Protože z definice je FS subsystém OS zodpovědný za efektivní správu zdroje „diskového prostoru“, což v případě Btrfs nevidíme. No představte si, že jste si přišli do obchodu koupit hodinky, abyste nepřišli pozdě do práce, a místo hodinek vám prodali elektrický gril s časovačem maximálně na 30 minut. Takže situace s Btrfs je ještě horší.

Při procházení e-mailových konferencí se často setkávám s tvrzením, že efektivně spravovat místo na disku již není vzhledem k lacinosti mechanik aktuální. To je úplný nesmysl. Bez účinného správce místa na disku se OS stane zranitelným a nepoužitelným. Bez ohledu na kapacitu disků na vašem počítači.

Chtěl bych požádat o komentář k ukončení podpory Btrfs v RHEL.

Zde není co komentovat, vše je velmi jasné. Měli to také jako „technologický náhled“. Takže jsem neprošel tímto "náhledem". Nenechte tento štítek viset navždy! Nemohou však uvést na trh chybný designový produkt s plnou podporou. RHEL je podnik, tedy předepsané vztahy mezi zbožím a penězi. Red Hat nemůže šikanovat uživatele jako na Btrfs mailing listu. Jen si představte situaci: klient, který zaplatil své těžce vydělané peníze za disk a také vám za podporu, chce pochopit, kam zmizelo jeho místo na disku poté, co si nic nezapsal. Co mu na to odpovíš?

Dále. Mezi klienty Red Hatu patří známé velké banky a směnárny. Představte si, co by se stalo, kdyby byli vystaveni DoS útokům na základě zmíněné zranitelnosti v Btrfs. Kdo za to podle vás může? Těm, kteří se chystají ukázat prstem na řádek licence GPL, kde je napsáno, že autor za nic neručí, hned řeknu: „schovejte to!“ Red Hat odpoví, a to tak, že se vám to nebude zdát dost! Ale vím, že Red Hat se s tímto druhem problému nepotýká, vzhledem k jejich obzvláště silnému týmu QA inženýrů, se kterými jsem měl příležitost úzce spolupracovat.

Proč některé společnosti nadále podporují Btrfs ve svých podnikových produktech?

Upozorňujeme, že předpona „podnik“ v názvu produktu mnoho neznamená. Podnik je mírou odpovědnosti zakotvené ve smluvním vztahu s klientem. Vím pouze o jednom podniku založeném na GNU/Linuxu - RHEL. Vše ostatní je z mého pohledu pouze prezentováno jako podnik, ale není jedním. A konečně, pokud je po něčem poptávka, tak vždy bude nabídka (v našem případě je to zmíněná „podpora“). Poptávka je úplně po všem, vč. a nepoužitelný software. Jak se taková poptávka tvoří a kdo ji živí, je jiné téma.

Takže bych nedělal ukvapené závěry poté, co se proslýchá, že Facebook nasadil na své servery Btrfs. Navíc bych z výše uvedených důvodů doporučoval pečlivě uchovávat adresy těchto serverů v tajnosti.

Proč bylo v poslední době vynaloženo tolik úsilí na vyčištění kódu XFS? Koneckonců, zpočátku se jedná o souborový systém třetí strany a ext4 je stabilní po dlouhou dobu a má návaznost na předchozí stejně stabilní verze. Jaký zájem má Red Hat o XFS? Má smysl aktivně vyvíjet dva účelově podobné souborové systémy – ext4 a XFS?

Nepamatuji si, co to motivovalo. Je docela možné, že iniciativa vzešla od klientů Red Hatu. Pamatuji si, že se prováděl výzkum tohoto druhu: na některých souborových systémech z upstreamu bylo vytvořeno obrovské množství objektů na špičkových discích nové generace. Podle výsledků se XFS chovalo lépe než ext4. Začali ji tedy propagovat jako nejperspektivnější. Každopádně nic senzačního bych zde nehledal.

Pro mě je to jako kdyby nahradili šídlo mýdlem. Nemá smysl vyvíjet ext4 a XFS. Jak paralelně, tak libovolná z nich na výběr. Nic dobrého z toho nevzejde. I když v přírodě často nastávají situace, kdy je velký potenciál k růstu, ale není kam růst. V tomto případě vznikají různé bizarně ošklivé novotvary, na které každý ukazuje prstem ("Ach, podívej, co v tomto životě neuvidíš!").

Myslíte si, že problém narušení vrstvy byl vyřešen (v negativním smyslu) s příchodem šifrovacích funkcí v ext4, F2FS (nemluvě o RAID v Btrfs)?

Obecně platí, že zavádění jakýchkoli úrovní a rozhodování o jejich neporušování je většinou věcí politiky a nezavazuji se zde nic komentovat. Objektivní aspekty narušení vrstvy nikoho nezajímají, ale některé z nich můžeme zvážit pomocí příkladu porušení „shora“, konkrétně implementace funkcionality ve FS, která již existuje na blokové vrstvě. Takové „porušení“ je oprávněné až na vzácné výjimky. Pro každý takový případ musíte nejprve prokázat dvě věci: že je to opravdu potřeba a že tím design systému neublíží.

Například zrcadlení, které bylo tradičně činností pro blokovou vrstvu, má smysl implementovat na úrovni souborového systému. Z různých důvodů. Například na diskových jednotkách dochází k „tichému“ poškození dat (bit rot). To je, když zařízení funguje správně, ale bloková data jsou nečekaně poškozena vlivem tvrdého gama kvanta emitovaného vzdáleným kvasarem atd. Nejhorší je, když se ukáže, že tento blok je systémový blok FS (superblok, bitmapový blok, uzel úložného stromu atd.), protože to jistě povede k panice jádra.

Upozorňujeme, že zrcadla, která nabízí bloková vrstva (tzv. RAID 1), vás tohoto problému nezachrání. No, opravdu: měl by někdo zkontrolovat kontrolní součty a přečíst repliku v případě selhání? Navíc má smysl zrcadlit nejen vše, ale pouze metadata. Některá důležitá data (například spustitelné soubory kritických aplikací) lze uložit jako metadata. V tomto případě dostávají stejné záruky bezpečnosti. Ochranu zbylých dat má smysl svěřit jiným subsystémům (možná i uživatelským aplikacím) – k tomu jsme zajistili všechny potřebné podmínky.

Taková „ekonomická“ zrcadla mají právo na existenci a mohou být efektivně organizována pouze na úrovni souborového systému. Jinak narušení vrstvení zahlcuje subsystém duplicitním kódem kvůli některým mikroskopickým výhodám. Pozoruhodným příkladem je implementace RAID-5 pomocí FS. Taková řešení (vlastní RAID / LVM v souborovém systému) zabíjejí ten druhý z architektonického hlediska. Zde je také třeba poznamenat, že porušování vrstvení je „uváděno do proudu“ různými druhy marketingových podvodníků. Při absenci jakýchkoliv nápadů je do subsystémů přidána funkce, která byla již dlouho implementována na sousedních úrovních, což je prezentováno jako nová extrémně užitečná funkce a je aktivně prosazována.

Reiser4 byl obviněn z porušení úrovní „zdola“. Na základě skutečnosti, že souborový systém není monolitický, jako všechny ostatní, ale modulární, vznikl nepodložený předpoklad, že dělá to, co by měla dělat výše uvedená úroveň (VFS).

Dá se mluvit o smrti ReiserFS v3.6 a například JFS? V poslední době se jim v jádru nevěnuje téměř žádná pozornost. Jsou zastaralé?

Zde musíme definovat, co znamená smrt softwarového produktu. Na jedné straně se úspěšně používají (proto byly ostatně stvořeny), což znamená, že žijí. Na druhou stranu nemůžu mluvit za JFS (moc toho neumím), ale ReiserFS (v3) se velmi těžko přizpůsobuje novým trendům (vyzkoušeno v praxi). To znamená, že v budoucnu nebudou vývojáři věnovat pozornost tomu, ale těm, které se snadněji přizpůsobí. Z této strany se ukazuje, že je bohužel architektonicky mrtvý. Vůbec bych nemanipuloval s pojmem „morálně zastaralý“. Dobře se vztahuje například na šatník, ale ne na softwarové produkty. V něčem existuje koncept podřízenosti a nadřazenosti. Mohu absolutně říci, že ReserFS v3 je nyní ve všem horší než Reiser4, ale v některých typech zátěže je lepší než všechny ostatní upstream FS.

Víte o vývoji FS Tux3 a HAMMER/HAMMER2 (FS pro DragonFly BSD)?

Ano, víme. V Tux3 mě kdysi zajímala technologie jejich snapshotů (takzvané “ukazatele verzí”), ale v Reiser4 půjdeme nejspíš jinou cestou. Dlouho jsem přemýšlel o podpoře snapshotů a ještě jsem se nerozhodl, jak je implementovat pro jednoduché svazky Reiser4. Faktem je, že nová technika „líného“ referenčního počítadla, kterou navrhl Ohad Rodeh, funguje pouze pro B-stromy. My je nemáme. Pro ty datové struktury, které se používají v Reiesr4, nejsou „líné“ čítače definovány - pro jejich zavedení je nutné vyřešit určité algoritmické problémy, které zatím nikdo nepřevzal.

Podle HAMMER: Četl jsem článek od tvůrce. Nemám zájem. Opět B-stromy. Tato datová struktura je beznadějně zastaralá. Opustili jsme to v minulém století.

Jak hodnotíte rostoucí poptávku po síťových clusterových FS jako CephFS/GlusterFS/atd? Znamená tento požadavek posun v prioritách vývojářů směrem k síťovému FS a nedostatečnou pozornost lokálnímu FS?

Ano, k takovému posunu priorit došlo. Vývoj lokálních souborových systémů stagnoval. Bohužel, udělat něco významného pro místní objemy je nyní poměrně obtížné a ne každý to dokáže. Nikdo nechce investovat do jejich rozvoje. To je asi to samé, jako byste požádali komerční organizaci, aby přidělila peníze na matematický výzkum – bez jakéhokoli nadšení se vás zeptají, jak můžete vydělat peníze na nové větě. Nyní je místní FS něco, co se magicky objeví „z krabice“ a „mělo by vždy fungovat“, a pokud nefunguje, způsobí neadresné reptání jako: „Ano, co si myslí!“

Z toho plyne nedostatek pozornosti místnímu FS, i když v této oblasti je stále hodně práce. A ano, všichni se obrátili na distribuované úložiště, které je postaveno na základě již existujících lokálních souborových systémů. Teď je to velmi módní. Fráze „Big Data“ vyvolává u mnohých adrenalin, spojuje ji s konferencemi, workshopy, velkými platy atd.

Jak rozumné je v zásadě implementovat síťový souborový systém v prostoru jádra spíše než v uživatelském prostoru?

Velmi rozumný přístup, který dosud nebyl nikde implementován. Obecně je otázka, v jakém prostoru by měl být síťový souborový systém implementován, „dvousečnou zbraní“. No, podívejme se na příklad. Klient zaznamenal data na vzdáleném počítači. Padly do její mezipaměti stránek v podobě špinavých stránek. Toto je úkol pro síťový souborový systém „tenké brány“ v prostoru jádra. Poté vás operační systém dříve nebo později požádá, abyste tyto stránky zapsali na disk, aby je uvolnil. Poté přichází na řadu IO-forwarding (odesílací) síťový FS modul. Určuje, na který serverový stroj (uzel serveru) tyto stránky půjdou.

Poté převezme řízení síťový zásobník (a jak víme, je implementován v prostoru jádra). Dále serverový uzel přijme tento paket s daty nebo metadaty a dá pokyn modulu backendového úložiště (tj. místnímu FS, který pracuje v prostoru jádra), aby všechny tyto věci zaznamenal. Otázku jsme tedy zredukovali na to, kde by měly fungovat moduly „odesílání“ a „přijímání“. Pokud některý z těchto modulů běží v uživatelském prostoru, nevyhnutelně to povede k přepínání kontextu (kvůli nutnosti používat služby jádra). Počet takových přepínačů závisí na detailech implementace.

Pokud je takových přepínačů mnoho, sníží se propustnost úložiště (výkon I/O). Pokud je vaše backendové úložiště tvořeno pomalými disky, pak nezaznamenáte výrazný pokles. Pokud ale máte rychlé disky (SSD, NVRAM atd.), pak se přepínání kontextu již stává „úzkým hrdlem“ a úsporou na přepínání kontextu lze výrazně zvýšit výkon. Standardní způsob, jak ušetřit peníze, je přesunout moduly do prostoru jádra. Zjistili jsme například, že přesun 9p serveru z QEMU do jádra na hostitelském počítači vede k trojnásobnému zvýšení výkonu VirtFS.

Toto samozřejmě není síťový FS, ale plně odráží podstatu věci. Nevýhodou této optimalizace jsou problémy s přenositelností. Pro některé může být to druhé kritické. Například GlusterFS nemá v jádře vůbec žádné moduly. Díky tomu nyní funguje na mnoha platformách včetně NetBSD.

Jaké koncepty by si místní FS mohly vypůjčit od síťových a naopak?

V dnešní době mají síťové FS zpravidla doplňky přes místní FS, takže úplně nechápu, jak si od nich můžete něco půjčit. No, skutečně, uvažujme společnost o 4 zaměstnancích, ve které si každý dělá to své: jeden distribuuje, druhý posílá, třetí přijímá, čtvrtý skladuje. A otázka, co si může firma půjčit od svého zaměstnance, který to skladuje, zní nějak nekorektně (co si od něj mohla půjčit už dávno má).

Místní FS se ale mají od síťových hodně co učit. Nejprve byste se od nich měli naučit, jak agregovat logické svazky na vysoké úrovni. Nyní tzv „pokročilé“ místní souborové systémy agregují logické svazky výhradně pomocí technologie „virtuálních zařízení“ vypůjčené od LVM (stejné narušení infekčního vrstvení, které bylo poprvé implementováno v ZFS). Jinými slovy, překlad virtuálních adres (čísla bloků) na skutečné a zpět probíhá na nízké úrovni (tj. poté, co souborový systém vydal I/O požadavek).

Vezměte prosím na vědomí, že přidávání a odebírání zařízení do logických svazků (nikoli zrcadlení) uspořádaných na blokové vrstvě vede k problémům, o kterých dodavatelé takových „funkcí“ skromně mlčí. Mluvím o fragmentaci na reálných zařízeních, která může dosahovat monstrózních hodnot, zatímco na virtuálním zařízení je vše v pořádku. Málokdo se však zajímá o virtuální zařízení: všechny zajímá, co se děje na vašich skutečných zařízeních. Ale FS podobné ZFS (stejně jako jakýkoli FS ve spojení s LVM) fungují pouze s virtuálními diskovými zařízeními (přidělují adresy virtuálních disků z volných, defragmentují tato virtuální zařízení atd.). A nemají ponětí, co se děje na skutečných zařízeních!

Nyní si představte, že na virtuálním zařízení máte nulovou fragmentaci (to znamená, že tam žije jen jedna obrovská oblast), přidáte disk do svého logického svazku a poté z logického svazku odeberete další náhodný disk a poté znovu vyvážíte. A tolikrát. Není těžké si představit, že na virtuálním zařízení budete stále stejně žít, ale na skutečných zařízeních nic dobrého neuvidíte.

Nejhorší je, že tuto situaci ani nejste schopni napravit! Jediné, co zde můžete udělat, je požádat systém souborů o defragmentaci virtuálního zařízení. Ale ona vám řekne, že je tam všechno skvělé – rozsah je jen jeden, fragmentace je nulová a lepší už to být nemůže! Logické svazky uspořádané na úrovni bloku tedy nejsou určeny pro opakované přidávání/odebírání zařízení. V dobrém slova smyslu stačí sestavit logický svazek na úrovni bloku pouze jednou, dát jej souborovému systému a pak s ním nic jiného nedělat.

Kromě toho kombinace nezávislých subsystémů FS+LVM neumožňuje zohlednit různou povahu jednotek, ze kterých jsou logické svazky agregovány. Předpokládejme, že jste sestavili logický svazek z HDD a polovodičových zařízení. Ale pak první bude vyžadovat defragmentaci a druhý ne. U posledně jmenovaného musíte vydávat žádosti o vyřazení, ale u prvního ne atd. V této kombinaci je však poměrně obtížné prokázat takovou selektivitu.

Všimněte si, že po vytvoření vlastního LVM na souborovém systému se situace o moc nezlepší. Navíc tím vlastně ukončíte vyhlídky na to, že to v budoucnu někdy vylepšíte. Toto je velmi špatné. Na stejném stroji mohou žít různé typy pohonů. A pokud je souborový systém nerozlišuje, pak kdo?

Další problém spočívá v čekání na tzv. Souborové systémy „Write-Anywhere“ (zahrnuje také Reiser4, pokud jste během připojení zadali vhodný transakční model). Takové souborové systémy musí poskytovat defragmentační nástroje, které jsou ve své síle bezprecedentní. A nízkoúrovňový správce hlasitosti zde nepomáhá, ale pouze překáží. Faktem je, že s takovým správcem bude vaše FS ukládat mapu volných bloků pouze jednoho zařízení - virtuálního. V souladu s tím můžete defragmentovat pouze virtuální zařízení. To znamená, že váš defragmentátor bude fungovat dlouhou, dlouhou dobu na obrovském jediném prostoru virtuálních adres.

A pokud máte hodně uživatelů, kteří provádějí náhodné přepisy, pak se užitečný efekt takového defragmentátoru sníží na nulu. Váš systém se nevyhnutelně začne zpomalovat a vy budete muset jen založit ruce před neuspokojivou diagnózou „rozbitý design“. Několik defragmentátorů běžících na stejném adresním prostoru se bude vzájemně rušit. Je to úplně jiná věc, pokud si udržujete vlastní mapu volných bloků pro každé skutečné zařízení. To efektivně paralelizuje proces defragmentace.

To však lze provést pouze v případě, že máte správce logických svazků na vysoké úrovni. Místní souborové systémy s takovými správci dříve neexistovaly (alespoň o nich nevím). Takové správce měly pouze síťové souborové systémy (například GlusterFS). Dalším velmi důležitým příkladem je nástroj pro kontrolu integrity svazku (fsck). Pokud pro každý podsvazek uložíte svou vlastní nezávislou mapu volných bloků, lze proceduru kontroly logického svazku efektivně paralelizovat. Jinými slovy, logické svazky s manažery na vysoké úrovni se lépe škálují.

Navíc s nízkoúrovňovými správci svazků nebudete moci organizovat plnohodnotné snímky. S LVM a souborovými systémy podobnými ZFS můžete pořizovat pouze lokální snímky, nikoli však globální snímky. Místní snímky umožňují okamžitě vrátit zpět pouze běžné operace se soubory. A nikdo tam nebude vracet operace s logickými svazky (přidávání/odebírání zařízení). Podívejme se na to na příkladu. V určitém okamžiku, když máte logický svazek dvou zařízení A a B obsahující 100 souborů, pořídíte snímek systému S a poté vytvoříte dalších sto souborů.

Poté přidáte zařízení C do svého svazku a nakonec vrátíte svůj systém zpět na snímek S. Otázka: Kolik souborů a zařízení obsahuje váš logický svazek po vrácení na S? Souborů bude 100, jak jste možná uhodli, ale budou to 3 zařízení - jedná se o stejná zařízení A, B a C, i když v době vytvoření snímku byla v systému pouze dvě zařízení (A a B ). Operace přidání zařízení C se nevrátila zpět, a pokud nyní odeberete zařízení C z počítače, poškodí vaše data, takže před odstraněním budete muset nejprve provést nákladnou operaci k odebrání zařízení z logického svazku pro opětovné vyvážení, což rozptýlí všechna data ze zařízení C do zařízení A a B. Pokud by ale váš FS podporoval globální snímky, nebylo by takové vyvažování vyžadováno a po okamžitém vrácení zpět na S byste mohli bezpečně odebrat zařízení C z počítače.

Globální snímky jsou tedy dobré, protože vám umožňují vyhnout se nákladnému odebrání (přidání) zařízení z logického svazku (do logického svazku) s velkým množstvím dat (samozřejmě, pokud si pamatujete „snímek“ systému ve správný čas). Dovolte mi připomenout, že vytváření snímků a jejich vrácení zpět do systému souborů jsou okamžité operace. Může vyvstat otázka: jak je vůbec možné okamžitě vrátit zpět operaci na logickém svazku, která vám zabrala tři dny? Ale je to možné! Za předpokladu, že je váš souborový systém správně navržen. S nápadem na takové „3D snímky“ jsem přišel před třemi lety a minulý rok jsem si tuto techniku ​​nechal patentovat.

Další věc, kterou by se místní FS měly naučit od síťových, je ukládat metadata na samostatná zařízení stejným způsobem, jakým je síťová FS ukládají na samostatné stroje (takzvané metadatové servery). Existují aplikace, které pracují primárně s metadaty, a tyto aplikace lze výrazně urychlit umístěním metadat na drahá vysoce výkonná úložná zařízení. S kombinací FS+LVM nebudete schopni prokázat takovou selektivitu: LVM neví, co je na bloku, který jste mu předali (data tam nebo metadata).

Z implementace vlastního nízkoúrovňového LVM ve FS nebudete mít velký užitek ve srovnání s kombinací FS+LVM, ale co můžete udělat velmi dobře, je zaneřádit FS tak, že později nebude možné s jeho kódem pracovat. ZFS a Btrfs, které se vrhly na virtuální zařízení, jsou jasnými příklady toho, jak narušení vrstvení zabíjí systém z architektonického hlediska. Tak proč to všechno dělám? Navíc není potřeba budovat svůj vlastní nízkoúrovňový LVM v souborovém systému. Místo toho musíte zařízení agregovat do logických svazků na vysoké úrovni, jak to dělají některé síťové systémy souborů s různými stroji (uzly úložiště). Je pravda, že to dělají nechutně kvůli použití špatných algoritmů.

Příklady naprosto příšerných algoritmů jsou DHT překladač v souborovém systému GlusterFS a takzvaná CRUSH mapa v souborovém systému Ceph. Žádný z algoritmů, které jsem viděl, mě neuspokojil z hlediska jednoduchosti a dobré škálovatelnosti. Musel jsem si tedy pamatovat algebru a vše vymýšlet sám. V roce 2015 jsem při experimentování se svazky nad hashovacími funkcemi vymyslel a patentoval něco, co mi vyhovuje. Nyní mohu říci, že pokus uvést toto vše do praxe byl úspěšný. V novém přístupu nevidím žádné problémy se škálovatelností.

Ano, každý podsvazek bude vyžadovat samostatnou strukturu, například superblok v paměti. Je to velmi děsivé? Obecně nevím, kdo „uvaří oceán“ a vytvoří logické objemy stovek tisíc nebo více zařízení na jednom místním počítači. Pokud mi to někdo dokáže vysvětlit, budu mu moc vděčná. Mezitím je to pro mě marketingová blbost.

Jak změny v subsystému jaderných blokových zařízení (například vzhled blk-mq) ovlivnily požadavky na implementaci FS?

Neměly žádný dopad. Nevím, co by se stalo na blokové vrstvě, kvůli čemuž by bylo nutné navrhnout nový FS. Interakční rozhraní těchto subsystémů je velmi špatné. Ze strany ovladače by se měl FS dotknout pouze vzhledu nových typů disků, kterým se nejprve přizpůsobí bloková vrstva a poté FS (pro reiser4 to bude znamenat vzhled nových pluginů).

Znamená vznik nových typů médií (například SMR nebo všudypřítomnost SSD) zásadně nové výzvy pro návrh souborového systému?

Ano. A to jsou normální pobídky pro rozvoj FS. Výzvy mohou být různé a zcela nečekané. Slyšel jsem například o jednotkách, kde rychlost I/O operace velmi závisí na velikosti dat a jejich offsetu. V Linuxu, kde velikost bloku FS nemůže přesáhnout velikost stránky, takový disk standardně neukáže své plné schopnosti. Pokud je však váš souborový systém navržen správně, pak existuje šance, že z něj získáte mnohem více.

Kolik lidí v současné době pracuje s kódem Reiser4 kromě vás?

Méně, než bych chtěl, ale nepociťuji ani akutní nedostatek zdrojů. S tempem vývoje Reiser4 jsem více než spokojen. Nebudu „řídit koně“ – to není ta správná oblast. Zde platí: "Pokud pojedete tišeji, budete pokračovat!" Moderní souborový systém je nejsložitějším jaderným subsystémem, jehož nesprávná rozhodnutí o návrhu mohou zrušit následující roky lidské práce.

Tím, že nabídnu dobrovolníkům, aby něco realizovali, vždy zaručuji, že vynaložené úsilí jistě povede ke správnému výsledku, který může být požadován pro vážné potřeby. Jak jste pochopili, nemůže být mnoho takových záruk najednou. Zároveň nesnesu „figurky“, které bezostyšně propagují „vlastnosti“ zjevně nepoužitelného softwaru, klamou stovky uživatelů a vývojářů, a přitom sedí a usmívají se na summitech jádra.

Vyjádřila některá společnost ochotu podpořit vývoj Reiser4?

Ano, byly takové návrhy, vč. a od významného prodejce. Ale kvůli tomu jsem se musel přestěhovat do jiné země. Bohužel už mi není 30 let, nemůžu se odtrhnout a odejít tak na první hvizd.

Jaké funkce aktuálně chybí Reiser4?

Pro jednoduché svazky neexistuje žádná funkce „změny velikosti“, podobná té, kterou najdete v ReiserFS(v3). Navíc by neuškodily operace se soubory s příznakem DIRECT_IO. Dále bych chtěl být schopen segregovat svazek na „sémantické podsvazky“, které nemají pevnou velikost a které lze připojit jako nezávislé svazky. Tyto problémy jsou dobré pro začátečníky, kteří si chtějí vyzkoušet „skutečnou věc“.

A nakonec bych chtěl mít síťové logické svazky s jednoduchou implementací a správou (moderní algoritmy to již umožňují). Co ale Reiser4 rozhodně nikdy mít nebude, je RAID-Z, scruby, mezipaměti volného místa, 128bitové proměnné a další marketingové nesmysly, které vznikly na pozadí nedostatku nápadů mezi vývojáři některých souborových systémů.

Lze vše, co může být potřeba, implementovat pomocí pluginů?

Pokud mluvíme pouze o rozhraních a pluginech (modulech), které je implementují, pak ne všechno. Pokud ale na těchto rozhraních zavedete i vztahy, pak mimo jiné budete mít koncepty vyšších polymorfismů, se kterými si již vystačíte. Představte si, že jste hypoteticky zmrazili objektově orientovaný runtime systém, změnili hodnotu ukazatele instrukce tak, aby ukazoval na jiný plugin, který implementuje stejné rozhraní X, a pak rozmrazíte systém, aby pokračoval ve vykonávání.

Pokud si koncový uživatel takové „substituce“ nevšimne, pak říkáme, že systém má polymorfismus nultého řádu v rozhraní X (nebo je systém heterogenní v rozhraní X, což je totéž). Pokud nyní máte nejen sadu rozhraní, ale máte na nich i vztahy (graf rozhraní), můžete zavést polymorfismy vyšších řádů, které budou charakterizovat heterogenitu systému již v „okolí“ jakéhokoli rozhraní. Takovou klasifikaci jsem zavedl už dávno, ale bohužel k tomu nikdy nedošlo.

Takže s pomocí pluginů a takových vyšších polymorfismů můžete popsat jakoukoli známou vlastnost, stejně jako „předpovědět“ ty, které nikdy nebyly ani zmíněny. Nepodařilo se mi to striktně dokázat, ale také zatím neznám protipříklad. Obecně mi tato otázka připomněla „Erlangen Program“ Felixe Kleina. Najednou se pokusil reprezentovat celou geometrii jako odvětví algebry (konkrétně teorie grup).

Nyní k hlavní otázce – jak to jde s povýšením Reiser4 na hlavní jádro? Byly nějaké publikace o architektuře tohoto souborového systému, o kterých jste hovořil v posledním rozhovoru? Jak relevantní je tato otázka z vašeho pohledu?

Obecně o zařazení do hlavní větve žádáme už tři roky. Poslední Reiserův komentář ve veřejném vláknu, kde byl požadavek na stažení proveden, zůstal bez odpovědi. Takže všechny další otázky nejsou pro nás. Osobně nechápu, proč se potřebujeme „sloučit“ do konkrétního operačního systému. Na Linuxu se světlo nesbíhalo jako klín. Existuje tedy samostatné úložiště, ve kterém bude několik portů větví pro různé operační systémy. Kdo potřebuje, může si naklonovat odpovídající port a dělat si s ním co chcete (samozřejmě v rámci licence). No, pokud to někdo nepotřebuje, pak to není můj problém. V tomto bodě navrhuji považovat otázku „povýšení do hlavního linuxového jádra“ za vyřešenou.

Publikace o architektuře FS jsou relevantní, ale zatím jsem si našel čas pouze na své nové výsledky, které považuji za vyšší prioritu. Další věc je, že jsem matematik a v matematice je jakákoli publikace souhrnem vět a jejich důkazů. Publikovat tam cokoliv bez důkazu je známka nevkusu. Pokud nějaké tvrzení o architektuře FS důkladně dokážu nebo vyvrátím, tak výsledkem budou takové hromady, že se prodírat bude dost těžké. kdo to potřebuje? To je pravděpodobně důvod, proč vše nadále zůstává ve své staré podobě - ​​zdrojový kód a komentáře k němu.

Co je nového v Reiser4 za posledních několik let?

Dlouho očekávaná stabilita se konečně zhmotnila. Jednou z posledních, která se objevila, byla chyba, která vedla k „nesmazatelným“ adresářům. Potíž byla v tom, že se objevil pouze na pozadí kolizí hash jmen a s určitým umístěním záznamů adresářů v uzlu stromu. Stále však nemohu doporučit Reiser4 pro produkci: k tomu musíte udělat nějakou práci s aktivní interakcí se správci produkčního systému.

Konečně se nám podařilo realizovat naši dlouholetou myšlenku – různé transakční modely. Dříve Reiser4 provozoval pouze jeden pevně zakódovaný model Macdonald-Reiser. To způsobilo problémy s designem. V takovém transakčním modelu zejména nejsou možné snímky - budou poškozeny atomickou komponentou nazvanou „SADA PŘEPISŮ“. Reiser4 aktuálně podporuje tři transakční modely. V jednom z nich (Write-Anywhere) atomická komponenta OVERWRITE SET obsahuje pouze systémové stránky (obrázky bitmap disku atd.), které nelze „vyfotografovat“ (problém slepice a vejce).

Takže obrázky lze nyní realizovat tím nejlepším možným způsobem. V jiném transakčním modelu jdou všechny upravené stránky pouze do OVERWRITE SET (to znamená, že jde v podstatě o čisté žurnálování). Tento model je pro ty, kteří si stěžovali na rychlou fragmentaci oddílů Reiser4. Nyní v tomto modelu nebude váš oddíl fragmentovat rychleji než s ReiserFS (v3). Všechny tři existující modely s jistými výhradami zaručují atomičnost operací, ale užitečné mohou být i modely se ztrátou atomicity a zachováním pouze celistvosti sekce. Takové modely mohou být užitečné pro všechny druhy aplikací (databáze atd.), které již některé z těchto funkcí převzaly. Je velmi snadné přidat tyto modely do Reiser4, ale neudělal jsem to, protože se mě nikdo neptal a já to osobně nepotřebuji.

Objevily se kontrolní součty metadat a nedávno jsem je doplnil o „ekonomická“ zrcadla“ (stále nestabilní materiál). Pokud selže kontrolní součet kteréhokoli bloku, Reiser4 okamžitě načte odpovídající blok z replikovaného zařízení. Všimněte si, že ZFS a Btrfs to neumí: design to neumožňuje. Tam musíte spustit speciální proces skenování na pozadí zvaný „scrub“ a počkat, až se dostane k problematickému bloku. Programátoři takové události obrazně nazývají „berličkami“.

A konečně se objevily heterogenní logické svazky nabízející vše, co ZFS, Btrfs, bloková vrstva, ale i kombinace FS+LVM v principu poskytnout nemohou - paralelní škálování, O(1) alokátor diskových adres, transparentní migraci dat mezi podsvazky. Ten má také uživatelské rozhraní. Nyní můžete snadno přesunout nejžhavější data na nejvýkonnější disk ve vašem svazku.

Navíc je možné na takový disk urgentně vyprázdnit všechny špinavé stránky, čímž se výrazně zrychlí aplikace, které často volají fsync(2). Podotýkám, že funkcionalita blokové vrstvy, nazývaná bcache, takovou svobodu jednání vůbec neposkytuje. Nové logické svazky jsou založeny na mých algoritmech (existují odpovídající patenty). Software je již poměrně stabilní, je docela možné jej vyzkoušet, měřit výkon atd. Jedinou nepříjemností je, že prozatím musíte ručně aktualizovat konfiguraci svazku a někde ji uložit.

Doposud jsem byl schopen realizovat své nápady z 10 procent, podařilo se mi však to, co jsem považoval za nejtěžší - propojení logických svazků s flash procedurou, která provádí všechny odložené akce v reiser4. To vše je stále v experimentální větvi „format41“.

Projde Reiser4 xfstesty?

Alespoň mně to tak bylo, když jsem připravoval poslední vydání.

Je možné v principu udělat z Reiser4 síťový (cluster) FS pomocí pluginů?

Je to možné a dokonce nutné! Pokud vytvoříte síťový soubor založený na správně navrženém lokálním souborovém systému, bude výsledek velmi působivý! V moderních síťových FS nejsem spokojen s přítomností úrovně backendového úložiště, které je implementováno pomocí libovolného lokálního FS. Existence této úrovně je zcela neopodstatněná. Síťový FS musí přímo interagovat s blokovou vrstvou a ne žádat místní FS, aby vytvářel nějaké další soubory služeb!

Obecně platí, že rozdělení souborových systémů na místní a síťové je od toho zlého. Vznikl z nedokonalosti algoritmů, které se používaly před třiceti lety a místo kterých dosud nebylo nic navrženo. To je také důvod, proč se objevuje množství nepotřebných softwarových komponent (různé služby atd.). V dobrém slova smyslu by měl být na každém stroji nainstalován pouze jeden FS ve formě modulu jádra a sady uživatelských utilit – uzel clusteru. Tento FS je lokální i síťový. A nic víc!

Pokud s Reiser4 na Linuxu nic nefunguje, rád bych nabídl FS pro FreeBSD (citace z předchozího rozhovoru: „...FreeBSD... má akademické kořeny... A to znamená, že s vysokou mírou pravděpodobnosti najde společný jazyk s vývojáři“) ?

Jak jsme tedy právě zjistili, s Linuxem již vše perfektně fungovalo: existuje pro něj samostatný funkční port Reiser4 v podobě hlavní větve našeho úložiště. Nezapomněl jsem na FreeBSD! Nabídka! Jsem připraven úzce spolupracovat s těmi, kteří dobře znají vnitřnosti FreeBSD. Mimochodem: na jejich komunitě se mi moc líbí, že tam rozhoduje aktualizovaná rada nezávislých odborníků, což nemá nic společného s vládním klamem jednoho stálého člověka.

Jak dnes hodnotíte komunitu uživatelů Linuxu? Stalo se to více „pop“?

Vzhledem k povaze mé práce je to pro mě dost těžké posoudit. Většinou za mnou uživatelé přicházejí s hlášeními o chybách a žádostmi o opravu sekce. Uživatelé jako uživatelé. Někteří jsou důvtipnější, někteří méně. S každým se zachází stejně. No, pokud uživatel ignoruje moje pokyny, tak mě omluvte: příkaz ignorování bude zadán i z mé strany.

Je možné předpovědět vývoj souborových systémů na dalších pět až deset let? Jaké jsou podle vás hlavní výzvy, kterým mohou vývojáři FS čelit?

Ano, udělat takovou předpověď není těžké. V upstreamu již dlouhou dobu neprobíhá žádný vývoj souborových systémů. Vytvoří se pouze zdání takového. Vývojáři lokálních souborových systémů narazili na problémy spojené se špatným designem. Zde je třeba učinit upozornění. Za vývoj a vývoj nepovažuji takzvané „skladování“, „lízání“ a portování kódu. A nedorozumění zvané „Btrfs“ neklasifikuji jako vývoj z důvodů, které jsem již vysvětlil.

Každý patch jen zhoršuje jeho problémy. Studna. a vždy existují různé druhy „evangelistů“, pro které „vše funguje“. V podstatě se jedná o školáky a studenty vynechávající přednášky. Jen si to představte: jemu to funguje, ale profesorovi ne. Co je to za adrenalin! Z mého pohledu největší škodu způsobují „řemeslníci“, kteří se vrhli nadšeně „našroubovat“ úžasné vlastnosti Btrfs na všemožné vrstvy jako systemd, docker atd. - to už připomíná metastázy.

Zkusme si nyní udělat předpověď na pět až deset let. Již jsem stručně vyjmenoval, co budeme v Reiser4 dělat. Hlavní výzvou pro místní vývojáře FS z upstreamu bude (ano, už se to stalo) nemožnost dělat slušnou práci za plat. Bez jakýchkoliv nápadů v oblasti ukládání dat se budou nadále pokoušet tyto nešťastné VFS, XFS a ext4 opravit. Zvláště komicky na tomto pozadí vypadá situace s VFS, která připomíná zběsilou modernizaci restaurace, ve které nejsou žádní kuchaři a žádní kuchaři se neočekávají.

Nyní kód VFS bez jakýchkoli podmínek uzamkne několik stránek paměti současně a vyzve základní FS, aby na nich pracoval. Toto bylo zavedeno pro zlepšení výkonu Ext4 při operacích mazání, ale jak je snadné pochopit, takové souběžné zamykání je zcela nekompatibilní s pokročilými transakčními modely. To znamená, že nebudete moci jednoduše přidat podporu pro nějaký inteligentní souborový systém v jádře. Nevím, jaká je situace v jiných oblastech Linuxu, ale pokud jde o souborové systémy, je nepravděpodobné, že by zde byl jakýkoli vývoj kompatibilní s politikou, kterou Torvalds v praxi prosazuje (akademické projekty jsou vykopávány a podvodníci, kteří netuším, jaký B-strom se vydávají nekonečné kredity důvěry). Proto byl nastaven kurz pomalého chátrání. Samozřejmě se budou ze všech sil snažit vydávat to za „vývoj“.

Kromě toho „správci“ souborových systémů, kteří si uvědomují, že jen „úložištěm“ nemůžete mnoho vydělat, se pokusí o ziskovější podnikání. Zpravidla se jedná o distribuované souborové systémy a virtualizaci. Možná přenesou módní ZFS někam jinam, kde ještě neexistuje. Ale stejně jako všechny FS z horního toku připomíná novoroční strom: pokud na něj můžete pověsit nějaké další malé věci, nemůžete se dostat hlouběji. Uznávám, že je možné vybudovat seriózní podnikový systém založený na ZFS, ale protože nyní diskutujeme o budoucnosti, mohu jen smutně konstatovat, že ZFS je v tomto ohledu beznadějný: se svými virtuálními zařízeními kluci odřízli kyslík pro sebe a budoucí generace pro další rozvoj. ZFS je minulostí. A ext4 a XFS nejsou ani předevčírem.

Samostatně stojí za zmínku o senzačním konceptu „linuxového souborového systému nové generace“. Toto je zcela politický a marketingový projekt vytvořený pro příležitost, abych tak řekl, „připevnit budoucnost souborových systémů“ v Linuxu za konkrétní postavy. Faktem je, že Linux býval „jen pro zábavu“. Nyní je to ale především stroj na vydělávání peněz. Vyrábějí se na všem možném. Je například velmi obtížné vytvořit dobrý softwarový produkt, ale chytří „vývojáři“ si již dávno uvědomili, že není třeba se vůbec napínat: můžete úspěšně prodat neexistující software, který byl oznámen a propagován na všech druzích veřejnosti. události - hlavní věc je, že prezentační snímky by měly obsahovat více „funkcí“.

Souborové systémy jsou k tomu jako stvořené, protože o výsledku můžete bez obav smlouvat deset let. Pokud si někdo později stěžuje na nedostatek tohoto výsledku, pak prostě nerozumí ničemu o souborových systémech! Připomíná to finanční pyramidu: na vrcholu jsou dobrodruzi, kteří tento nepořádek začali, a těch pár, kteří měli „štěstí“: „vybrali dividendy“, tzn. dostávali peníze na rozvoj, dostali dobře placenou práci manažerů, „ukazovali se“ na konferencích atd.

Dále následují ti, kteří mají „smůlu“: budou počítat ztráty, řešit důsledky nasazení nepoužitelného softwarového produktu do výroby, „atd. Je jich mnohem více. No, na základně pyramidy je obrovská masa vývojářů, kteří „řežou“ zbytečný kód. Jsou to největší poražení, protože promarněný čas nelze vrátit. Takové pyramidy jsou pro Torvaldse a jeho společníky nesmírně prospěšné. A čím více těchto pyramid, tím lépe pro ně. Aby se takové pyramidy nakrmily, do jádra lze vzít cokoli. Samozřejmě na veřejnosti říkají opak. Ale nesoudím podle slov, ale podle činů.

Takže „budoucnost souborových systémů v Linuxu“ je dalším vysoce propagovaným, ale stěží použitelným softwarem. Po Btrfs s velkou pravděpodobností místo takové „budoucnosti“ zaujme Bcachefs, což je další pokus o křížení linuxové blokové vrstvy se souborovým systémem (špatný příklad je nakažlivý). A co je typické: jsou tam stejné problémy jako v Btrfs. Dlouho jsem to tušil a pak jsem nějak neodolal a podíval se do kódu - je to pravda!

Autoři Bcachefů a Btrfs při tvorbě svých FS aktivně využívali cizích zdrojů a málo jim rozuměli. Situace velmi připomíná dětskou hru „rozbitý telefon“. A zhruba si dokážu představit, jak bude tento kód obsažen v jádře. Ve skutečnosti „hrábla“ nikdo neuvidí (všichni na ně šlápnou později). Po četných dohadech o stylu kódu, obviněních z neexistujících porušení atd., bude učiněn závěr o „loajalitě“ autora, o tom, jak dobře „interaguje“ s ostatními vývojáři a jak úspěšně to vše může poté prodány korporacím.

Konečný výsledek nebude nikoho zajímat. Možná před dvaceti lety by mě to zajímalo, ale nyní jsou otázky položeny jinak: bude možné toto prosazovat, aby byli někteří lidé zaměstnáni během příštích deseti let. A bohužel není zvykem divit se konečnému výsledku.

Obecně bych důrazně nedoporučoval začít znovu objevovat systém souborů od začátku. Protože ani nemalé finanční investice nebudou stačit na to, abychom za deset let získali něco konkurenceschopného. Samozřejmě mluvím o seriózních projektech a ne o těch, které mají být „vtlačeny“ do jádra. Takže efektivnější způsob, jak se vyjádřit, je připojit se ke skutečnému vývoji, jako jsme my. To samozřejmě není snadné – ale to je případ každého projektu na vysoké úrovni.

Nejprve budete muset samostatně překonat problém, který vám nabídnu. Poté, přesvědčen o vážnosti vašich úmyslů, začnu pomáhat. Tradičně používáme pouze vlastní vývoj. Výjimkou jsou kompresní algoritmy a některé hashovací funkce. Neposíláme vývojáře cestovat na konference a pak nesedáme a nekombinujeme cizí nápady („možná, co se stane“), jak je u většiny startupů zvykem.

Všechny algoritmy vyvíjíme sami. V současné době se zajímám o algebraické a kombinatorické aspekty vědy o ukládání dat. Zejména konečná tělesa, asymptotika, důkaz nerovnic. Existuje také práce pro běžné programátory, ale musím vás hned varovat: všechny návrhy „podívat se na jiný FS a udělat totéž“ jsou ignorovány. Půjdou tam i patche zaměřené na užší integraci s Linuxem přes VFS.

Nemáme tedy hrábě, ale rozumíme tomu, kam se musíme posunout, a věříme, že tento směr je správný. Toto pochopení nepřišlo ve formě manny z nebe. Dovolte mi připomenout, že máme za sebou 29 let zkušeností s vývojem, dva souborové systémy napsané od začátku. A stejný počet nástrojů pro obnovu dat. A tohle je hodně!

Zdroj: opennet.ru