Bol zverejnený druhý rozhovor s Eduardom Shishkinom, vývojárom súborového systému Reiser4.
Na začiatok pripomeňte čitateľom, kde a pre koho pracujete.
Pracujem ako hlavný architekt úložiska v Huawei Technologies, nemeckom výskumnom centre. Na oddelení virtualizácie sa zaoberám rôznymi aspektmi ukladania dát. Moje aktivity nesúvisia s konkrétnym operačným systémom.
V súčasnosti sa zaväzujete k hlavnej vetve jadra?
Veľmi zriedka, a iba ak to vyžaduje môj zamestnávateľ. Naposledy asi pred tromi rokmi som poslal záplaty na zvýšenie priepustnosti úložiska zdieľaného na hostiteľoch pomocou protokolu 9p (iný názov pre tento biznis je VirtFS). Tu je potrebné poznamenať jednu dôležitú poznámku: aj keď s Linuxom pracujem už dlho, nikdy som nebol jeho fanúšikom, to znamená, že „dýcham rovnomerne“, ako pri všetkom inom. Najmä ak si všimnem nejaký nedostatok, môžem naň upozorniť maximálne raz. A aby ste potom mohli niekoho sledovať a presviedčať - to sa nestane.
Pamätám si, že naposledy pred desiatimi rokmi ste boli dosť kritickí voči štýlu vývoja jadra. Z vášho (alebo možno korporátneho) pohľadu sa niečo zmenilo, stala sa komunita citlivejšou alebo nie? Ak nie, kto je podľa vás na vine?
Nevidel som žiadne pozitívne zmeny. Hlavným problémom komunity je nahrádzanie vedy politickými technológiami, osobnými vzťahmi, väčšinovým názorom, populizmom, radami od „vnútorných hlasov“, prehnitými kompromismi – čímkoľvek, len nie vedou. Informatika, bez ohľadu na to, ako sa na ňu pozeráte, je v prvom rade exaktná veda. A ak niekto začne hlásať význam pre 2x2, ktorý sa líši od 4, pod hlavičkou „...Linux spôsobom“ alebo akýmkoľvek iným, potom je nepravdepodobné, že by to prinieslo niečo iné ako škodu.
Všetky problémy sú primárne spôsobené neschopnosťou a nedostatočným vzdelaním tých, ktorí rozhodujú. Ak je manažér nekompetentný, nie je schopný urobiť objektívne, adekvátne rozhodnutie. Ak je navyše nekultúrny, nie je schopný nájsť kompetentného odborníka, ktorý mu správne poradí. S vysokou pravdepodobnosťou padne voľba na podvodníka, ktorý hovorí „zdanlivo správne veci“. Okolo neschopných osamelých vodcov sa vždy vyvinie skorumpované prostredie. Navyše, história v tomto smere nepozná výnimky a komunita je toho najjasnejším potvrdením.
Ako hodnotíte pokrok vo vývoji Btrfs? Zbavila sa táto FS detských chorôb? Ako ho umiestnite pre seba – ako FS „na doma“ alebo aj na firemné použitie?
Nezbavil som sa toho. Všetko, čo som spomenul pred 11 rokmi, je aktuálne aj dnes. Jedným z problémov s Btrfs, ktorý ho robí nevhodným pre vážne potreby, je problém voľného miesta. O tom, že používateľ je vyzvaný, aby si zabehol do obchodu pre nový disk, ani nehovorím v situáciách, kedy by akýkoľvek iný FS ukazoval veľa voľného miesta na partícii. Nemožnosť dokončiť operáciu na logickom zväzku z dôvodu nedostatku voľného miesta tiež nie je to najhoršie. Najhoršie je, že neprivilegovaný používateľ môže takmer vždy obísť akékoľvek diskové kvóty a pripraviť každého o voľné miesto v pomerne krátkom čase.
Vyzerá to takto (testované pre jadro) Linux 5.12). Na novo nainštalovanom systéme sa spustí skript, ktorý v slučke vytvára súbory so špecifickými názvami v domovskom adresári, zapisuje do nich dáta na špecifických offsetoch a potom tieto súbory vymaže. Po minúte spustenia tohto skriptu sa nič nezvyčajné nestane. Po piatich minútach sa obsadené miesto na oddiele mierne zvýši. Po dvoch až troch hodinách dosiahne 50 % (z počiatočnej hodnoty 15 %). A po piatich až šiestich hodinách skript zlyhá s chybou „na oddiele nie je voľné miesto“. Potom už nemôžete na oddiel zapísať ani 4K súbor.
Nastane zaujímavá situácia: nakoniec ste do oddielu nič nezapísali a všetko voľné miesto (asi 85%) niekde zmizlo. Analýza úseku, ktorý je vystavený takémuto útoku, odhalí mnoho uzlov stromu obsahujúcich len jednu položku (objekt vybavený kľúčom) s veľkosťou niekoľkých bajtov. To znamená, že obsah, ktorý predtým zaberal 15% miesta na disku, sa ukázal byť rovnomerne „rozmazaný“ po celom oddiele, takže nie je kam zapísať nový súbor, pretože jeho kľúč je väčší ako všetky existujúce a voľný bloky na oddiele sa minuli.
Toto všetko sa navyše deje už na základnej konfigurácii Btrfs (bez akýchkoľvek snímok, podzväzkov atď.) a nezáleží na tom, ako sa rozhodnete uložiť telá súborov v tomto FS (ako „fragmenty“ v strome alebo ako rozsahy neformátovaných blokov) - konečný výsledok bude rovnaký.
Iné upstream súborové systémy nebudete môcť vystaviť takémuto útoku (bez ohľadu na to, čo vám povedia). Príčinu problému som vysvetlil už dávno: ide o úplnú perverziu konceptu B-stromu v Btrfs, ktorý umožňuje jeho spontánnu alebo zámernú degeneráciu. Najmä pri určitých zaťaženiach sa váš súborový systém neustále „rozpadá“ počas prevádzky sám, bez vonkajšej pomoci. Je jasné, že všelijaké procesy „stláčania“ na pozadí zachránia deň len na jednotlivých desktopoch.
Na kolektívnych servery Útočník ich bude vždy môcť „predbehnúť“. Správca systému ani nebude schopný určiť, kto ho presne zneužíval. Najrýchlejší spôsob, ako tento problém v Btrfs vyriešiť, je obnoviť štruktúru bežného B-stromu, t. j. prepracovať formát disku a prepísať významnú časť kódu Btrfs. To bude trvať 8 – 10 rokov vrátane ladenia, za predpokladu, že vývojári prísne dodržiavali pôvodné dokumenty o príslušných algoritmoch a dátových štruktúrach a nehrali „rozbitý telefón“, ako je zvykom (a odporúčané) v...Linux spôsob“.
Tu musíme pripočítať aj čas potrebný na to, aby to všetko vývojári pochopili. Tu je to ťažšie. V každom prípade im 10 rokov nestačilo na pochopenie. No dovtedy nemôžete dúfať v zázrak. Nestane sa to vo forme možnosti montáže, „o ktorej sme vy ani ja nevedeli“, alebo vo forme opravy, ktorú je potrebné pripraviť „len vecou podnikania“. Pre každú takúto unáhlenú „nápravu“ predstavím nový scenár degenerácie. B-stromy sú jednou z mojich obľúbených tém a musím povedať, že tieto štruktúry netolerujú slobody so sebou samým!
Ako umiestnim Btrfs pre seba? Ako niečo, čo sa absolútne nedá nazvať súborovým systémom, nieto ešte použiť. Pretože podľa definície je FS subsystém OS zodpovedný za efektívne riadenie zdroja „priestoru na disku“, čo v prípade Btrfs nevidíme. No predstavte si, že ste si prišli do obchodu kúpiť hodinky, aby ste nemeškali do práce a namiesto hodiniek vám predali elektrický gril s časovačom maximálne na 30 minút. Takže situácia s Btrfs je ešte horšia.
Pri prezeraní zoznamov adries sa často stretávam s tvrdením, že efektívne spravovať miesto na disku už nie je relevantné kvôli lacnosti jednotiek. To je úplný nezmysel. Bez efektívneho správcu miesta na disku sa OS stane zraniteľným a nepoužiteľným. Bez ohľadu na kapacitu diskov vo vašom počítači.
Chcel by som požiadať o komentár k ukončeniu podpory Btrfs v RHEL.
Nie je tu nič zvláštne na komentár, všetko je veľmi jasné. Mali to aj ako „technologický náhľad“. Takže som neprešiel týmto „ukážkou“. Nenechajte tento štítok visieť navždy! Nemôžu však uviesť na trh chybný dizajnový produkt s plnou podporou. RHEL je podnik, teda predpísané komoditno-peňažné vzťahy. Red Hat nemôže šikanovať používateľov tak, ako to robia v zozname adries Btrfs. Len si predstavte situáciu: klient, ktorý zaplatil svoje ťažko zarobené peniaze za disk a tiež vám za podporu, chce pochopiť, kde sa stratilo miesto na jeho disku, keď si nič nezapísal. Čo mu na to odpoviete?
Ďalej. Medzi klientov Red Hatu patria známe veľké banky a burzy. Predstavte si, čo by sa stalo, keby boli vystavení DoS útokom na základe spomínanej zraniteľnosti v Btrfs. Kto je podľa vás za to zodpovedný? Tým, ktorí sa chystajú ukázať prstom na riadok GPL licencie, kde je napísané, že autor za nič nezodpovedá, hneď poviem: „schovaj to!“ Red Hat odpovie, a to tak, že sa vám to nebude zdať dosť! Viem však, že Red Hat týmto problémom nečelí, vzhľadom na ich mimoriadne silný tím inžinierov kontroly kvality, s ktorými som mal možnosť svojho času úzko spolupracovať.
Prečo niektoré spoločnosti naďalej podporujú Btrfs vo svojich podnikových produktoch?
Všimnite si, že predpona „enterprise“ v názve produktu veľa neznamená. Enterprise je miera zodpovednosti zakotvená v zmluvnom vzťahu s klientom. Poznám iba jeden enterprise založený na GNU.Linux — to je RHEL. Všetko ostatné sa podľa mňa len maskuje ako podnik, ale nie je. A nakoniec, ak je po niečom dopyt, vždy bude aj ponuka (v našom prípade je to spomínaná „podpora“). Dopyt môže byť úplne po všetkom, vrátane nepoužiteľného softvéru. Ako sa tento dopyt tvorí a kto ho živí, je úplne iná téma.
Takže by som nerobil žiadne unáhlené závery po tom, čo sa hovorí, že Facebook nasadil Btrfs na svoje servery. Navyše, adresy týchto... serverov Z vyššie uvedených dôvodov by som to odporučil starostlivo utajiť.
Prečo bolo v poslednej dobe vynaložené toľko úsilia na čistenie kódu XFS? Koniec koncov, spočiatku ide o súborový systém tretej strany a ext4 je stabilný po dlhú dobu a má kontinuitu z predchádzajúcich rovnako stabilných verzií. Aký záujem má Red Hat o XFS? Má zmysel aktívne vyvíjať dva súborové systémy podobného účelu – ext4 a XFS?
Nepamätám si, čo to motivovalo. Je dosť možné, že iniciatíva prišla od klientov Red Hatu. Pamätám si, že sa uskutočnil výskum tohto druhu: na niektorých súborových systémoch z upstreamu sa vytvorilo obrovské množstvo objektov na špičkových diskoch novej generácie. Podľa výsledkov sa XFS správal lepšie ako ext4. Začali ju teda propagovať ako najperspektívnejšiu. V každom prípade by som tu nehľadal nič senzačné.
Pre mňa je to ako keby nahradili šidlo mydlom. Nemá zmysel vyvíjať ext4 a XFS. Súbežne aj ľubovoľný z nich na výber. Nič dobré z toho nebude. Aj keď v prírode sa často vyskytujú situácie, keď existuje veľký potenciál na rast, ale nie je priestor na rast. V tomto prípade vznikajú rôzne bizarne škaredé novotvary, na ktoré každý ukazuje prstom („Ach, pozri, čo v tomto živote neuvidíš!“).
Myslíte si, že problém porušovania vrstiev sa vyriešil (v negatívnom zmysle) príchodom šifrovacích funkcií v ext4, F2FS (nehovoriac o RAID v Btrfs)?
Vo všeobecnosti je zavádzanie akýchkoľvek úrovní a rozhodovanie o ich neporušovaní väčšinou vecou politiky a nezaväzujem sa tu nič komentovať. Objektívne aspekty porušenia vrstvy nikoho nezaujímajú, ale niektoré z nich môžeme zvážiť pomocou príkladu porušenia „zhora“, konkrétne implementácie funkčnosti vo FS, ktorá už existuje na blokovej vrstve. Takéto „porušenie“ je odôvodnené len na ojedinelé výnimky. Pre každý takýto prípad musíte najskôr dokázať dve veci: že je to naozaj potrebné a že tým nepoškodí dizajn systému.
Napríklad zrkadlenie, ktoré je tradične činnosťou pre blokovú vrstvu, má zmysel implementovať na úrovni súborového systému. Z rôznych dôvodov. Napríklad na diskových jednotkách dochádza k „tichému“ poškodeniu údajov (bitová hniloba). Vtedy zariadenie funguje správne, no blokové dáta sú nečakane poškodené vplyvom tvrdého gama kvanta vyžarovaného vzdialeným kvazarom atď. Najhoršie je, ak sa tento blok ukáže ako systémový blok FS (superblok, bitmapový blok, uzol úložného stromu atď.), pretože to určite povedie k panike v jadre.
Upozorňujeme, že zrkadlá, ktoré ponúka bloková vrstva (tzv. RAID 1), vás tohto problému nezachránia. No, naozaj: mal by niekto skontrolovať kontrolné súčty a prečítať si repliku v prípade zlyhania? Okrem toho má zmysel zrkadliť nielen všetko, ale iba metadáta. Niektoré dôležité údaje (napríklad spustiteľné súbory kritických aplikácií) možno uložiť ako metadáta. V tomto prípade dostávajú rovnaké záruky bezpečnosti. Ochranu zvyšných dát má zmysel zveriť iným subsystémom (možno aj užívateľským aplikáciám) – na to sme zabezpečili všetky potrebné podmienky.
Takéto „ekonomické“ zrkadlá majú právo na existenciu a môžu byť efektívne organizované iba na úrovni súborového systému. V opačnom prípade porušenie vrstvenia zahlcuje subsystém duplicitným kódom kvôli niektorým mikroskopickým výhodám. Pozoruhodným príkladom je implementácia RAID-5 pomocou FS. Takéto riešenia (vlastný RAID / LVM v súborovom systéme) ho z architektonického hľadiska zabíjajú. Tu treba tiež poznamenať, že porušovanie vrstvenia „uvádzajú do prúdu“ rôzne druhy marketingových podvodníkov. Pri absencii akýchkoľvek nápadov sa do podsystémov pridáva funkcionalita, ktorá je už dlho implementovaná na susedných úrovniach, čo je prezentované ako nová mimoriadne užitočná funkcia a aktívne sa presadzuje.
Reiser4 bol obvinený z porušenia úrovní „zdola“. Na základe skutočnosti, že súborový systém nie je monolitický, ako všetky ostatné, ale modulárny, vznikol nepodložený predpoklad, že robí to, čo by mala robiť úroveň vyššie (VFS).
Dá sa hovoriť o smrti ReiserFS v3.6 a napríklad JFS? V poslednej dobe sa im v jadre nevenovala takmer žiadna pozornosť. Sú zastarané?
Tu musíme definovať, čo znamená smrť softvérového produktu. Na jednej strane sa úspešne používajú (na to boli predsa stvorené), čo znamená, že žijú. Na druhej strane nemôžem hovoriť za JFS (veľa toho neviem), ale ReiserFS (v3) sa veľmi ťažko prispôsobuje novým trendom (testované v praxi). To znamená, že v budúcnosti nebudú vývojári venovať pozornosť tomu, ale tým, ktoré sa ľahšie prispôsobia. Z tejto strany sa ukazuje, že je, žiaľ, z architektonického hľadiska mŕtvy. Vôbec by som nemanipuloval s pojmom „morálne zastaraný“. Dobre sa to vzťahuje napríklad na šatník, ale nie na softvérové produkty. V niečom existuje pojem menejcennosti a nadradenosti. Môžem absolútne povedať, že ReserFS v3 je teraz vo všetkom horší ako Reiser4, ale v niektorých typoch pracovného zaťaženia je lepší ako všetky ostatné upstream FS.
Viete o vývoji FS Tux3 a HAMMER/HAMMER2 (FS pre DragonFly BSD)?
Áno, vieme. V Tux3 ma kedysi zaujímala technológia ich snímok (tzv. “ukazovatele verzií”), no v Reiser4 pôjdeme s najväčšou pravdepodobnosťou inou cestou. Už dlho som premýšľal o podpore snapshotov a ešte som sa nerozhodol, ako ich implementovať pre jednoduché zväzky Reiser4. Faktom je, že nová technika „lenivého“ referenčného počítadla, ktorú navrhol Ohad Rodeh, funguje iba pre B-stromy. My ich nemáme. Pre dátové štruktúry, ktoré sa používajú v Reiesr4, nie sú definované „lenivé“ počítadlá - na ich zavedenie je potrebné vyriešiť určité algoritmické problémy, ktoré zatiaľ nikto neprebral.
Podľa HAMMER: Čítal som článok od tvorcu. Nezaujíma. Opäť B-stromy. Táto dátová štruktúra je beznádejne zastaraná. V minulom storočí sme to opustili.
Ako hodnotíte rastúci dopyt po sieťových klastrových FS ako CephFS/GlusterFS/atď. Znamená táto požiadavka posun priorít vývojárov smerom k sieťovým FS a nedostatočnú pozornosť lokálnym FS?
Áno, k takémuto posunu priorít došlo. Vývoj lokálnych súborových systémov stagnoval. Bohužiaľ, urobiť niečo významné pre miestne objemy je teraz dosť ťažké a nie každý to dokáže. Nikto nechce investovať do ich rozvoja. To je asi to isté, ako keby ste požiadali komerčnú organizáciu, aby pridelila peniaze na matematický výskum – bez akéhokoľvek nadšenia sa vás opýtajú, ako môžete zarobiť peniaze na novej vete. Teraz je lokálny FS niečo, čo sa kúzelne objavuje „ako z krabice“ a „malo by vždy fungovať“, a ak nefunguje, spôsobuje neadresné reptanie typu: „Áno, čo si myslia!“
Preto nedostatočná pozornosť miestnemu FS, hoci v tejto oblasti je stále veľa práce. A áno, každý sa obrátil na distribuované úložisko, ktoré je postavené na základe už existujúcich lokálnych súborových systémov. Teraz je to veľmi módne. Fráza „Big Data“ spôsobuje mnohým adrenalín, spája sa s konferenciami, workshopmi, veľkými platmi atď.
Aké rozumné je v princípe implementovať sieťový súborový systém v priestore jadra a nie v používateľskom priestore?
Veľmi rozumný prístup, ktorý ešte nebol nikde zavedený. Vo všeobecnosti je otázka, v akom priestore by mal byť sieťový súborový systém implementovaný, „dvojsečná zbraň“. Nuž, pozrime sa na príklad. Klient zaznamenával údaje na vzdialený počítač. Padali do jej cache stránok v podobe špinavých stránok. Toto je úloha pre sieťový súborový systém „tenkej brány“ v priestore jadra. Potom vás operačný systém skôr či neskôr požiada, aby ste tieto stránky zapísali na disk, aby ich uvoľnili. Potom prichádza na rad IO-forwarding (odosielanie) sieťový FS modul. Určuje, na ktorý serverový stroj (uzol servera) tieto stránky pôjdu.
Potom to prevezme sieťový zásobník (a ako vieme, je implementovaný v priestore jadra). Potom serverový uzol prijme tento paket s údajmi alebo metaúdajmi a dá pokyn modulu backendového úložiska (t. j. lokálnemu FS, ktorý pracuje v priestore jadra), aby všetky tieto veci zaznamenal. Takže sme otázku zredukovali na to, kde by mali fungovať moduly „odosielanie“ a „prijímanie“. Ak niektorý z týchto modulov beží v užívateľskom priestore, nevyhnutne to povedie k prepínaniu kontextu (kvôli potrebe používať služby jadra). Počet takýchto prepínačov závisí od detailov implementácie.
Ak je takýchto prepínačov veľa, priepustnosť úložiska (výkon I/O) sa zníži. Ak je vaše backendové úložisko tvorené pomalými diskami, výrazný pokles nezaznamenáte. Ak však máte rýchle disky (SSD, NVRAM atď.), prepínanie kontextu sa už stáva „úzkym hrdlom“ a šetrením na prepínaní kontextu možno výrazne zvýšiť výkon. Štandardným spôsobom, ako ušetriť peniaze, je presunúť moduly do priestoru jadra. Napríklad sme zistili, že presun servera 9p z QEMU do jadra na hostiteľskom počítači vedie k trojnásobnému zvýšeniu výkonu VirtFS.
Toto samozrejme nie je sieťový FS, ale plne odráža podstatu veci. Nevýhodou tejto optimalizácie sú problémy s prenosnosťou. Pre niektorých môže byť to druhé kritické. Napríklad GlusterFS nemá v jadre vôbec žiadne moduly. Vďaka tomu teraz funguje na mnohých platformách vrátane NetBSD.
Aké koncepty by si mohli lokálne FS požičať od sieťových a naopak?
V súčasnosti majú sieťové FS spravidla doplnky cez lokálne FS, takže celkom nerozumiem, ako si od nich môžete niečo požičať. Nuž, uvažujme o firme so 4 zamestnancami, v ktorej si každý robí po svojom: jeden distribuuje, druhý posiela, tretí prijíma, štvrtý skladuje. A otázka, čo si môže firma požičať od svojho zamestnanca, ktorý to skladuje, znie akosi nesprávne (to, čo si od neho mohla požičať už dávno má).
Ale lokálne FS sa majú čo učiť od sieťových. Po prvé, mali by ste sa od nich naučiť, ako agregovať logické zväzky na vysokej úrovni. Teraz tzv „Pokročilé“ lokálne súborové systémy agregujú logické zväzky výlučne pomocou technológie „virtuálnych zariadení“ požičanej od LVM (rovnaké infekčné narušenie vrstvenia, ktoré bolo prvýkrát implementované v ZFS). Inými slovami, preklad virtuálnych adries (čísla blokov) na skutočné a späť nastáva na nízkej úrovni (t. j. potom, čo súborový systém vydal požiadavku na vstup/výstup).
Upozorňujeme, že pridávanie a odstraňovanie zariadení do logických zväzkov (nie zrkadiel) usporiadaných na blokovej vrstve vedie k problémom, o ktorých dodávatelia takýchto „funkcií“ skromne mlčia. Hovorím o fragmentácii na reálnych zariadeniach, ktorá môže dosahovať obludné hodnoty, zatiaľ čo na virtuálnom je všetko v poriadku. Málokto sa však zaujíma o virtuálne zariadenia: všetkých zaujíma, čo sa deje na vašich skutočných zariadeniach. Ale FS podobné ZFS (rovnako ako každý FS v spojení s LVM) fungujú len s virtuálnymi diskovými zariadeniami (prideľujú adresy virtuálnych diskov spomedzi voľných, defragmentujú tieto virtuálne zariadenia atď.). A netušia, čo sa deje na skutočných zariadeniach!
Teraz si predstavte, že na virtuálnom zariadení máte nulovú fragmentáciu (to znamená, že tam máte len jeden obrovský rozsah), pridáte disk do svojho logického zväzku a potom z logického zväzku odstránite ďalší náhodný disk a potom znova vyvážite. A toľkokrát. Nie je ťažké si predstaviť, že na virtuálnom zariadení budete stále žiť v rovnakej miere, ale na skutočných zariadeniach neuvidíte nič dobré.
Najhoršie je, že túto situáciu ani nedokážete napraviť! Jediné, čo tu môžete urobiť, je požiadať systém súborov o defragmentáciu virtuálneho zariadenia. Ale ona vám povie, že tam je všetko skvelé - je tam len jeden rozsah, fragmentácia je nulová a nemôže to byť lepšie! Logické zväzky usporiadané na úrovni bloku teda nie sú určené na opakované pridávanie/odstraňovanie zariadení. V dobrom slova zmysle stačí zhromaždiť logický zväzok na úrovni bloku len raz, dať ho súborovému systému a potom s ním nič iné nerobiť.
Okrem toho kombinácia nezávislých subsystémov FS+LVM neumožňuje brať do úvahy rôznu povahu jednotiek, z ktorých sa agregujú logické zväzky. Predpokladajme, že ste zostavili logický zväzok z pevného disku a polovodičových zariadení. Ale potom prvý bude vyžadovať defragmentáciu a druhý nie. V prípade druhého musíte vydať žiadosti o vyradenie, ale v prípade prvého nie atď. V tejto kombinácii je však dosť ťažké preukázať takúto selektivitu.
Všimnite si, že po vytvorení vlastného LVM na súborovom systéme sa situácia veľmi nezlepší. Navyše tým vlastne ukončíte vyhliadky na jeho zlepšenie v budúcnosti. Toto je veľmi zlé. Na tom istom stroji môžu fungovať rôzne typy pohonov. A ak medzi nimi súborový systém nerozlišuje, kto to bude robiť?
Ďalší problém spočíva v čakaní na tzv. Súborové systémy „Write-Anywhere“ (sem patrí aj Reiser4, ak ste počas pripojenia zadali vhodný transakčný model). Takéto súborové systémy musia poskytovať nástroje na defragmentáciu, ktoré sú vo svojej sile bezprecedentné. A nízkoúrovňový správca hlasitosti tu nepomôže, ale iba prekáža. Faktom je, že s takýmto manažérom si váš FS uloží mapu voľných blokov len jedného zariadenia - virtuálneho. V súlade s tým môžete defragmentovať iba virtuálne zariadenie. To znamená, že váš defragmentátor bude fungovať dlho, dlho na obrovskom jedinom priestore virtuálnych adries.
A ak máte veľa používateľov, ktorí robia náhodné prepisy, užitočný efekt takéhoto defragmentátora sa zníži na nulu. Váš systém sa nevyhnutne začne spomaľovať a vy budete musieť len založiť ruky pred sklamanou diagnózou „rozbitý dizajn“. Niekoľko defragmentátorov bežiacich na rovnakom adresnom priestore sa bude vzájomne ovplyvňovať. Je to úplne iná záležitosť, ak si udržiavate vlastnú mapu voľných blokov pre každé skutočné zariadenie. Tým sa efektívne zjednotí proces defragmentácie.
Dá sa to však urobiť iba vtedy, ak máte správcu logických zväzkov na vysokej úrovni. Lokálne súborové systémy s takýmito manažérmi predtým neexistovali (aspoň o nich neviem). Takýchto manažérov mali iba sieťové súborové systémy (napríklad GlusterFS). Ďalším veľmi dôležitým príkladom je nástroj na kontrolu integrity zväzku (fsck). Ak si pre každý podzväzok uložíte vlastnú nezávislú mapu voľných blokov, potom možno efektívne paralelizovať postup kontroly logického zväzku. Inými slovami, logické zväzky s manažérmi na vysokej úrovni sa lepšie škálujú.
Navyše s nízkoúrovňovými manažérmi zväzkov nebudete môcť organizovať plnohodnotné snímky. S LVM a súborovými systémami podobnými ZFS môžete robiť iba lokálne snímky, nie však globálne snímky. Lokálne snímky vám umožňujú okamžite vrátiť späť iba bežné operácie so súbormi. A nikto tam nebude vracať späť operácie s logickými zväzkami (pridávanie/odstraňovanie zariadení). Pozrime sa na to na príklade. V určitom okamihu, keď máte logický zväzok dvoch zariadení A a B obsahujúci 100 súborov, urobíte snímku systému S a potom vytvoríte ďalších sto súborov.
Potom pridáte zariadenie C do svojho zväzku a nakoniec vrátite svoj systém späť na snímku S. Otázka: Koľko súborov a zariadení obsahuje váš logický zväzok po návrate na S? Súborov bude 100, ako ste možno uhádli, ale budú to 3 zariadenia – ide o rovnaké zariadenia A, B a C, hoci v čase vytvorenia snímky boli v systéme iba dve zariadenia (A a B ). Operácia pridania zariadenia C sa nevrátila späť a ak teraz odstránite zariadenie C z počítača, poškodí to vaše údaje, takže pred odstránením budete musieť najskôr vykonať nákladnú operáciu na odstránenie zariadenia z logického zväzku na opätovné vyváženie, čo rozptýli všetky dáta zo zariadenia C do zariadení A a B. Ak však váš FS podporoval globálne snímky, takéto preváženie by nebolo potrebné a po okamžitom návrate na S by ste mohli bezpečne odstrániť zariadenie C z počítača.
Globálne snímky sú teda dobré, pretože vám umožňujú vyhnúť sa nákladnému odstráneniu (pridaniu) zariadenia z logického zväzku (do logického zväzku) s veľkým množstvom údajov (samozrejme, ak si nezabudnete „snímať“ váš systém v správnom čase). Dovoľte mi pripomenúť, že vytváranie snímok a vrátenie súborového systému do nich sú okamžité operácie. Môže vyvstať otázka: ako je vôbec možné okamžite vrátiť späť operáciu na logickom zväzku, ktorá vám trvala tri dni? Ale je to možné! Za predpokladu, že váš súborový systém je navrhnutý správne. S nápadom na takéto „3D snímky“ som prišiel pred tromi rokmi a minulý rok som si túto techniku nechal patentovať.
Ďalšia vec, ktorú by sa miestne FS mali naučiť od sieťových, je ukladať metadáta na samostatné zariadenia rovnakým spôsobom, akým ich sieťové FS ukladajú na samostatné počítače (takzvané metaúdajové servery). Existujú aplikácie, ktoré pracujú primárne s metadátami a tieto aplikácie je možné výrazne urýchliť umiestnením metadát na drahé vysokovýkonné úložné zariadenia. S kombináciou FS+LVM nebudete môcť preukázať takú selektivitu: LVM nevie, čo je na bloku, ktorý ste mu odovzdali (dáta tam alebo metadáta).
V porovnaní s kombináciou FS+LVM nezískate veľký úžitok z implementácie vlastného nízkoúrovňového LVM vo FS, ale to, čo môžete urobiť veľmi dobre, je neporiadok FS tak, že neskôr nebude možné pracovať s jeho kódom. ZFS a Btrfs, ktoré sa ponáhľali s virtuálnymi zariadeniami, sú jasnými príkladmi toho, ako porušovanie vrstiev zabíja systém z architektonického hľadiska. Navyše nie je potrebné inštalovať svoj vlastný nízkoúrovňový LVM v súborovom systéme. Namiesto toho musíte zariadenia agregovať do logických zväzkov na vysokej úrovni, ako to robia niektoré sieťové súborové systémy s rôznymi strojmi (uzlami úložiska). Je pravda, že to robia nechutne kvôli použitiu zlých algoritmov.
Príkladmi úplne hrozných algoritmov sú prekladač DHT v súborovom systéme GlusterFS a takzvaná mapa CRUSH v systéme súborov Ceph. Žiadny z algoritmov, ktoré som videl, ma neuspokojil z hľadiska jednoduchosti a dobrej škálovateľnosti. Musel som si teda zapamätať algebru a všetko vymyslieť sám. V roku 2015 som pri experimentovaní so zväzkami nad hashovacími funkciami vymyslel a patentoval niečo, čo mi vyhovuje. Teraz môžem povedať, že pokus uviesť toto všetko do praxe bol úspešný. V novom prístupe nevidím žiadne problémy so škálovateľnosťou.
Áno, každý podzväzok bude vyžadovať samostatnú štruktúru, napríklad superblok v pamäti. Je to veľmi strašidelné? Vo všeobecnosti neviem, kto „uvarí oceán“ a vytvorí logické objemy stoviek tisíc alebo viac zariadení na jednom miestnom počítači. Ak mi to niekto dokáže vysvetliť, budem mu veľmi vďačný. Medzitým je to pre mňa marketingový nezmysel.
Ako ovplyvnili zmeny v subsystéme blokových zariadení jadra (napríklad vzhľad blk-mq) požiadavky na implementáciu FS?
Nemali žiadny vplyv. Neviem, čo by sa stalo na blokovej vrstve, kvôli čomu by bolo potrebné navrhnúť nový FS. Interakčné rozhranie týchto subsystémov je veľmi zlé. Zo strany ovládača by sa mal FS dotknúť len vzhľadu nových typov diskov, ktorým sa najskôr prispôsobí bloková vrstva a až potom FS (pre reiser4 to bude znamenať vzhľad nových pluginov).
Znamená vznik nových typov médií (napríklad SMR alebo všadeprítomnosť SSD) zásadne nové výzvy pre návrh súborového systému?
Áno. A to sú normálne stimuly pre rozvoj FS. Výzvy môžu byť rôzne a úplne nečakané. Počul som napríklad o jednotkách, kde rýchlosť I/O operácie do veľkej miery závisí od veľkosti údajov a ich posunu. V Linuxe, kde veľkosť bloku FS nemôže presiahnuť veľkosť stránky, takýto disk štandardne neukáže svoje plné možnosti. Ak je však váš súborový systém navrhnutý správne, potom existuje šanca, že z neho vyťažíte oveľa viac.
Koľko ľudí momentálne pracuje s kódom Reiser4 okrem vás?
Menej, ako by som chcel, ale nepociťujem ani akútny nedostatok zdrojov. S tempom vývoja Reiser4 som viac než spokojný. Nebudem „riadiť kone“ – toto nie je tá správna oblasť. Tu platí: "Ak budete jazdiť tichšie, budete pokračovať!" Moderný súborový systém je najkomplexnejší kernelový subsystém, ktorého nesprávne rozhodnutia o návrhu môžu vrátiť späť roky ľudskej práce.
Tým, že ponúknem dobrovoľníkom niečo realizovať, vždy garantujem, že vynaložené úsilie určite povedie k správnemu výsledku, ktorý si môže vyžadovať seriózna potreba. Ako viete, nemôže existovať veľa takýchto záruk naraz. Zároveň nemôžem vystáť „figúrky“, ktoré bezostyšne propagujú „vlastnosti“ zjavne nepoužiteľného softvéru, klamú stovky používateľov a vývojárov a zároveň sedia a usmievajú sa na summitoch jadra.
Vyjadrila niektorá spoločnosť ochotu podporiť vývoj Reiser4?
Áno, boli také návrhy, vr. a od významného predajcu. Ale kvôli tomu som sa musel presťahovať do inej krajiny. Bohužiaľ, už nemám 30 rokov, nemôžem sa odtrhnúť a odísť tak pri prvom hvizde.
Aké funkcie momentálne v Reiser4 chýbajú?
Pre jednoduché zväzky neexistuje žiadna funkcia „zmeny veľkosti“, podobná tej, ktorá sa nachádza v ReiserFS(v3). Okrem toho by neboli na škodu ani operácie so súbormi s príznakom DIRECT_IO. Ďalej by som chcel byť schopný rozdeliť zväzok na „sémantické podzväzky“, ktoré nemajú pevnú veľkosť a ktoré možno pripojiť ako nezávislé zväzky. Tieto problémy sú dobré pre začiatočníkov, ktorí si chcú vyskúšať „skutočnú vec“.
A nakoniec by som chcel mať sieťové logické zväzky s jednoduchou implementáciou a správou (moderné algoritmy to už umožňujú). Čo však Reiser4 určite nikdy mať nebude, je RAID-Z, scruby, cache voľného miesta, 128-bitové premenné a ďalšie marketingové nezmysly, ktoré vznikli na pozadí nedostatku nápadov medzi vývojármi niektorých súborových systémov.
Je možné všetko potrebné implementovať pomocou doplnkov?
Ak hovoríme len o rozhraniach a pluginoch (moduloch), ktoré ich implementujú, tak nie všetko. Ale ak na týchto rozhraniach zavediete aj vzťahy, tak okrem iného budete mať aj koncepty vyšších polymorfizmov, s ktorými si už vystačíte. Predstavte si, že by ste hypoteticky zmrazili objektovo orientovaný runtime systém, zmenili hodnotu ukazovateľa inštrukcie tak, aby ukazoval na iný doplnok, ktorý implementuje rovnaké rozhranie X, a potom rozmrazíte systém, aby pokračoval vo vykonávaní.
Ak si koncový používateľ nevšimne takúto „substitúciu“, potom hovoríme, že systém má polymorfizmus nultého rádu v rozhraní X (alebo je systém heterogénny v rozhraní X, čo je to isté). Ak teraz máte nielen množinu rozhraní, ale máte na nich aj vzťahy (graf rozhrania), môžete zaviesť polymorfizmy vyšších rádov, ktoré budú charakterizovať heterogenitu systému už v „susedstve“ akéhokoľvek rozhrania. Takúto klasifikáciu som zaviedol už dávno, ale, žiaľ, nikdy sa tak nestalo.
Takže pomocou pluginov a takýchto vyšších polymorfizmov môžete opísať akúkoľvek známu vlastnosť, ako aj „predpovedať“ tie, o ktorých sa nikdy ani nehovorilo. Nepodarilo sa mi to striktne dokázať, ale zatiaľ nepoznám ani protipríklad. Vo všeobecnosti mi táto otázka pripomenula „program Erlangen“ od Felixa Kleina. Kedysi sa snažil reprezentovať celú geometriu ako odvetvie algebry (konkrétne teórie grúp).
Teraz k hlavnej otázke – ako to ide s povýšením Reiser4 na hlavné jadro? Boli nejaké publikácie o architektúre tohto súborového systému, o ktorých ste hovorili v poslednom rozhovore? Nakoľko je táto otázka z vášho pohľadu relevantná?
Vo všeobecnosti už tri roky žiadame o zaradenie do hlavnej pobočky. Posledný Reiserov komentár vo verejnom vlákne, kde bola žiadosť o stiahnutie vykonaná, zostal nezodpovedaný. Takže všetky ďalšie otázky nie sú pre nás. Osobne nerozumiem, prečo sa musíme „zlúčiť“ do konkrétneho operačného systému. Na Linuxe sa svetlo nezbiehalo ako klin. Existuje teda samostatné úložisko, v ktorom bude niekoľko portov pobočiek pre rôzne operačné systémy. Kto to potrebuje, môže si naklonovať príslušný port a robiť si s ním čo chcete (samozrejme v rámci licencie). No ak to niekto nepotrebuje, tak to nie je môj problém. V tomto bode navrhujem považovať otázku „postupu do hlavného linuxového jadra“ za vyriešenú.
Publikácie o architektúre FS sú relevantné, ale zatiaľ som si našiel čas len na svoje nové výsledky, ktoré považujem za vyššiu prioritu. Ďalšia vec je, že som matematik a v matematike je akákoľvek publikácia súhrnom viet a ich dôkazov. Publikovať tam čokoľvek bez dôkazu je znakom nevkusu. Ak nejaké tvrdenie o architektúre FS dôsledne dokážem alebo vyvrátim, tak výsledkom budú také kopy, cez ktoré sa bude dosť ťažko prechádzať. kto to potrebuje? Pravdepodobne preto všetko naďalej zostáva vo svojej starej podobe – zdrojový kód a komentáre k nemu.
Čo je nové v Reiser4 za posledných pár rokov?
Dlho očakávaná stabilita sa konečne zhmotnila. Jednou z posledných, ktorá sa objavila, bola chyba, ktorá viedla k „nevymazateľným“ adresárom. Problém bol v tom, že sa objavil iba na pozadí kolízií hash mien a s určitým umiestnením záznamov adresára v uzle stromu. Stále však nemôžem odporučiť Reiser4 pre produkciu: na to musíte urobiť nejakú prácu s aktívnou interakciou so správcami produkčného systému.
Konečne sa nám podarilo zrealizovať našu dlhoročnú myšlienku – rôzne transakčné modely. Predtým Reiser4 prevádzkoval iba jeden pevne zakódovaný model Macdonald-Reiser. To spôsobilo problémy s dizajnom. Najmä v takomto transakčnom modeli nie sú možné snímky - budú poškodené atómovým komponentom s názvom „SADA PREPISU“. Reiser4 v súčasnosti podporuje tri transakčné modely. V jednom z nich (Write-Anywhere) obsahuje atómová zložka OVERWRITE SET iba systémové stránky (obrazy bitových máp disku atď.), ktoré sa nedajú „odfotiť“ (problém sliepky a vajíčka).
Takže obrázky môžu byť teraz realizované tým najlepším možným spôsobom. V inom transakčnom modeli idú všetky upravené stránky iba do SET PREPÍSAŤ (to znamená, že ide v podstate o čisté žurnálovanie). Tento model je pre tých, ktorí sa sťažovali na rýchlu fragmentáciu oddielov Reiser4. Teraz v tomto modeli sa váš oddiel nebude fragmentovať rýchlejšie ako s ReiserFS (v3). Všetky tri existujúce modely s určitými výhradami zaručujú atomickosť operácií, ale užitočné môžu byť aj modely so stratou atomickosti a zachovaním len celistvosti sekcie. Takéto modely môžu byť užitočné pre všetky druhy aplikácií (databázy atď.), ktoré už prevzali niektoré z týchto funkcií. Je veľmi jednoduché pridať tieto modely do Reiser4, ale neurobil som to, pretože sa ma nikto nepýtal a ja to osobne nepotrebujem.
Objavili sa kontrolné súčty metadát a nedávno som ich doplnil o „ekonomické“ zrkadlá“ (stále nestabilný materiál). Ak zlyhá kontrolný súčet ktoréhokoľvek bloku, Reiser4 okamžite načíta príslušný blok z replikovaného zariadenia. Upozorňujeme, že ZFS a Btrfs to nedokážu: dizajn to neumožňuje. Tam musíte spustiť špeciálny proces skenovania na pozadí nazývaný „scrub“ a počkať, kým sa dostane k problematickému bloku. Programátori takéto udalosti obrazne nazývajú „barle“.
A napokon sa objavili heterogénne logické zväzky, ktoré ponúkajú všetko, čo ZFS, Btrfs, bloková vrstva, ako aj kombinácie FS+LVM v princípe nedokážu poskytnúť – paralelné škálovanie, O(1) diskový alokátor adries, transparentnú migráciu dát medzi podzväzkami. Ten má aj používateľské rozhranie. Teraz môžete jednoducho presunúť najhorúcejšie dáta na najvýkonnejší disk vo vašom zväzku.
Okrem toho je možné urýchlene vyprázdniť všetky špinavé stránky na takýto disk, čím sa výrazne urýchlia aplikácie, ktoré často volajú fsync(2). Podotýkam, že funkcionalita blokovej vrstvy, nazývaná bcache, takúto slobodu konania vôbec neposkytuje. Nové logické zväzky sú založené na mojich algoritmoch (existujú zodpovedajúce patenty). Softvér je už pomerne stabilný, je celkom možné ho vyskúšať, merať výkon atď. Jedinou nepríjemnosťou je, že zatiaľ musíte manuálne aktualizovať konfiguráciu zväzku a niekde ju uložiť.
Zatiaľ sa mi podarilo zrealizovať moje nápady na 10 percent. Podarilo sa mi však to, čo som považoval za najťažšie – prepojenie logických zväzkov s flash procedúrou, ktorá vykonáva všetky odložené akcie v reiser4. To všetko je stále v experimentálnej vetve „format41“.
Prejde Reiser4 xfstestami?
Aspoň mne to tak bolo, keď som pripravoval posledné vydanie.
Je možné v princípe urobiť z Reiser4 sieťový (klastrový) FS pomocou pluginov?
Je to možné a dokonca nevyhnutné! Ak vytvoríte sieťový súbor založený na správne navrhnutom lokálnom súborovom systéme, výsledok bude veľmi pôsobivý! V moderných sieťových FS nie som spokojný s prítomnosťou úrovne backendového úložiska, ktoré je implementované pomocou akéhokoľvek lokálneho FS. Existencia tejto úrovne je úplne neopodstatnená. Sieťový FS musí priamo interagovať s blokovou vrstvou a nie žiadať lokálny FS, aby vytváral akékoľvek iné servisné súbory!
Vo všeobecnosti je delenie súborových systémov na lokálne a sieťové od toho zlého. Vznikol z nedokonalosti algoritmov, ktoré sa používali pred tridsiatimi rokmi a namiesto ktorých ešte nebolo nič navrhnuté. To je tiež dôvod, prečo sa objavuje množstvo nepotrebných softvérových komponentov (rôzne služby atď.). V dobrom slova zmysle by mal byť na každom stroji nainštalovaný iba jeden FS vo forme modulu jadra a sady užívateľských utilít – uzol klastra. Tento FS je lokálny aj sieťový. A nič viac!
Ak s Reiser4 v LinuxAk z toho nikdy nič nebude, rád by som navrhol FS pre FreeBSD (citát z predchádzajúceho rozhovoru: „...FreeBSD ... má akademické korene... A to znamená, že s vysokou pravdepodobnosťou nájdeme spoločný jazyk s vývojármi“)?
Ako sme teda práve zistili, s Linuxom už všetko fungovalo perfektne: existuje preň samostatný funkčný port Reiser4 vo forme hlavnej vetvy nášho úložiska. Nezabudol som na FreeBSD! Ponuka! Som pripravený úzko spolupracovať s tými, ktorí dobre poznajú vnútro FreeBSD. Mimochodom: na ich komunite sa mi veľmi páči, že rozhodnutia tam robí aktualizovaná rada nezávislých odborníkov, čo nemá nič spoločné s vládnym klamaním jedného stáleho človeka.
Ako hodnotíte používateľskú komunitu? Linux dnes? Stalo sa to viac „popovým“?
Vzhľadom na charakter mojej práce je to pre mňa dosť ťažké posúdiť. Používatelia za mnou väčšinou prichádzajú s hláseniami o chybách a žiadosťami o opravu sekcie. Používatelia ako používatelia. Niektorí sú dôvtipnejší, niektorí menej. S každým sa zaobchádza rovnako. No ak používateľ ignoruje moje pokyny, tak ma ospravedlňte: príkaz na ignorovanie bude zadaný aj z mojej strany.
Dá sa predpovedať vývoj súborových systémov na najbližších päť až desať rokov? Aké sú podľa vás hlavné výzvy, ktorým môžu vývojári FS čeliť?
Áno, urobiť takúto predpoveď nie je ťažké. V upstreame už dlho neprebiehal žiadny vývoj súborových systémov. Vytvára sa len zdanie takých. Vývojári lokálnych súborových systémov narazili na problémy spojené so zlým dizajnom. Tu je potrebné upozorniť. Za vývoj a vývoj nepovažujem takzvané „ukladanie“, „lízanie“ a portovanie kódu. A nedorozumenie s názvom „Btrfs“ neklasifikujem ako vývoj z dôvodov, ktoré som už vysvetlil.
Každá náplasť len zhoršuje jeho problémy. Dobre. a vždy existujú rôzne druhy „evanjelistov“, ktorým „všetko funguje“. V podstate ide o školákov a študentov vynechávajúcich prednášky. Len si to predstavte: jemu to funguje, ale profesorovi nie. Aký je to adrenalín! Z môjho pohľadu najväčšiu škodu spôsobujú „remeselníci“, ktorí sa vrhli s nadšením „naskrutkovať“ úžasné vlastnosti Btrfs na najrôznejšie vrstvy ako systemd, docker atď. - toto už pripomína metastázy.
Skúsme teraz urobiť predpoveď na päť až desať rokov. Čo budeme robiť v Reiser4 som už stručne vymenoval. Hlavnou výzvou pre lokálnych vývojárov FS z upstreamu bude (áno, už sa to stalo) neschopnosť robiť poriadnu prácu za plat. Bez akýchkoľvek nápadov v oblasti ukladania dát sa budú naďalej pokúšať o opravu týchto nešťastných VFS, XFS a ext4. Obzvlášť komicky na tomto pozadí vyzerá situácia s VFS, ktorá pripomína šialenú modernizáciu reštaurácie, v ktorej nie sú šéfkuchári a ani sa neočakávajú.
Kód VFS teraz bezpodmienečne uzamkne viacero pamäťových stránok súčasne a požiada podkladový súborový systém, aby s nimi operoval. Toto bolo zavedené s cieľom zlepšiť výkon Ext4 počas operácií mazania, ale ako ľahko pochopíte, takéto súčasné uzamknutie je úplne nekompatibilné s pokročilými transakčnými modelmi. To znamená, že do jadra nemôžete jednoducho pridať podporu pre nejaký druh inteligentného súborového systému. Neviem, ako je to v iných oblastiach. LinuxAle pokiaľ ide o súborové systémy, akýkoľvek vývoj tu je sotva kompatibilný s politikou, ktorú Torvalds v skutočnosti presadzuje (akademické projekty sú vylučované a podvodníci, ktorí netušia, čo je B-strom, dostávajú nekonečné uznanie). Preto bol nastavený kurz pomalého úpadku. Samozrejme, budú sa snažiť čo najviac to vydávať za „vývoj“.
Okrem toho „správcovia“ súborových systémov, ktorí si uvedomujú, že len „skladovaním“ nemôžete veľa zarobiť, vyskúšajú ziskovejší biznis. Ide spravidla o distribuované súborové systémy a virtualizáciu. Možno prenesú módny ZFS niekde inde, kde ešte neexistuje. Ale rovnako ako všetky FS z horného toku sa podobá novoročnému stromu: ak môžete na vrch zavesiť nejaké iné malé veci, nemôžete sa dostať hlbšie. Pripúšťam, že je možné vybudovať seriózny podnikový systém založený na ZFS, ale keďže teraz diskutujeme o budúcnosti, môžem len smutne konštatovať, že ZFS je v tomto ohľade beznádejný: chalani svojimi virtuálnymi zariadeniami odrezali kyslík pre seba a budúce generácie pre ďalší rozvoj. ZFS je minulosťou. A ext4 a XFS nie sú ani predvčerom.
Za zmienku stojí osobitne aj často diskutovaný koncept „Linux súborový systém novej generácie.“ Ide o čisto politický a marketingový projekt, vytvorený s cieľom takpovediac „vymedziť budúcnosť súborových systémov“ v Linux pre konkrétne postavy. Ide o to, že kedysi to bolo Linux Kedysi to bolo „len pre zábavu“. Teraz je to predovšetkým stroj na zarábanie peňazí. Peniaze sa zarábajú na všetkom možnom. Napríklad vytvoriť dobrý softvérový produkt je veľmi ťažké, ale inteligentní „vývojári“ si už dávno uvedomili, že sa netreba vôbec namáhať: aj neexistujúci softvér, ohlásený a propagovaný na najrôznejších verejných podujatiach, sa dá úspešne predať – hlavné je mať na prezentačných slajdoch dostatok funkcií.
Súborové systémy sú na to ako stvorené, pretože o výsledku môžete pokojne vyjednávať aj desať rokov. No, ak sa niekto neskôr sťažuje na nedostatok tohto výsledku, potom jednoducho nerozumie ničomu o súborových systémoch! Pripomína to finančnú pyramídu: na vrchole sú dobrodruhovia, ktorí tento chaos začali, a tých pár, ktorí mali „šťastie“: „vybrali dividendy“, t.j. dostali peniaze na rozvoj, dostali dobre platenú prácu manažérov, „ukázali sa“ na konferenciách atď.
Na rad prichádzajú tí, ktorí majú „smolu“: budú počítať straty, riešiť následky nasadenia nepoužiteľného softvérového produktu do výroby atď. Je ich oveľa viac. No, na základni pyramídy je obrovská masa vývojárov, ktorí „pília“ zbytočný kód. Sú najväčšími porazenými, pretože premárnený čas sa nedá vrátiť. Takéto pyramídy sú mimoriadne prospešné pre Torvaldsa a jeho spoločníkov. A čím viac týchto pyramíd, tým lepšie pre nich. Na kŕmenie takýchto pyramíd je možné do jadra vziať čokoľvek. Samozrejme, na verejnosti hovoria opak. Ale nesúdim podľa slov, ale podľa činov.
Takže „budúcnosť súborových systémov Linuxu“ je ďalší veľmi propagovaný, ale zle použiteľný softvér. Po Btrfs je veľmi pravdepodobné, že túto „budúcnosť“ nahradí Bcachefs, čo je ďalší pokus o kríženie... Linux Bloková vrstva so súborovým systémom (zlý príklad je nákazlivý). A zaujímavé je, že má rovnaké problémy ako Btrfs. Dlho som to tušil a potom som neodolal a pozrel som sa na kód – a je to pravda!
Autori Bcachefov a Btrfov pri vytváraní svojich FS aktívne využívali cudzie zdroje, pričom im málo rozumeli. Situácia veľmi pripomína detskú hru „poškodený telefón“. A viem si zhruba predstaviť, ako bude tento kód zahrnutý do jadra. V skutočnosti nikto neuvidí „hrable“ (všetci na ne stúpia neskôr). Po mnohých dohadoch o štýle kódu, obvineniach z neexistujúcich porušení atď. sa dospeje k záveru o „lojalite“ autora, o tom, ako dobre „interaguje“ s ostatnými vývojármi a ako úspešne to všetko môže potom predať korporáciám.
Konečný výsledok nebude nikoho zaujímať. Možno pred dvadsiatimi rokmi by ma to zaujímalo, ale teraz sú otázky položené inak: bude možné to presadzovať, aby sa v najbližších desiatich rokoch zamestnali určití ľudia. A, bohužiaľ, nie je zvykom čudovať sa konečnému výsledku.
Vo všeobecnosti by som dôrazne neodporúčal začať znovu objavovať váš súborový systém od začiatku. Pretože ani značné finančné investície nebudú stačiť na získanie niečoho konkurencieschopného o desať rokov. Samozrejme, hovorím o serióznych projektoch, a nie o tých, ktoré sú určené na „vloženie“ do jadra. Efektívnejším spôsobom, ako sa vyjadriť, je zapojiť sa do skutočného vývoja, ako sme my. To, samozrejme, nie je ľahké – ale to je prípad každého projektu na vysokej úrovni.
Najprv budete musieť samostatne prekonať problém, ktorý vám ponúknem. Potom, presvedčený o vážnosti vašich úmyslov, začnem pomáhať. Tradične používame iba náš vlastný vývoj. Výnimkou sú kompresné algoritmy a niektoré hašovacie funkcie. Neposielame vývojárov cestovať na konferencie a potom nesedíme a nespájame nápady iných ľudí („možno, čo sa stane“), ako je zvykom vo väčšine startupov.
Všetky algoritmy si vyvíjame sami. Momentálne ma zaujímajú algebraické a kombinatorické aspekty vedy o ukladaní dát. Najmä konečné polia, asymptotika a nerovnosti. Práca je tu aj pre bežných programátorov, ale musím vás hneď varovať: všetky návrhy „pozrite sa na iný súborový systém a urobte to isté“ budú ignorované. Záplaty zamerané na užšiu integráciu s Linux cez linku VFS.
Nemáme teda hrable, ale rozumieme tomu, kam sa musíme posunúť, a sme presvedčení, že tento smer je správny. Toto pochopenie neprišlo vo forme manny z neba. Pripomínam, že máme za sebou 29 rokov skúseností s vývojom, dva súborové systémy napísané od začiatku. A rovnaký počet nástrojov na obnovu dát. A toto je veľa!
Zdroj: opennet.ru
