Objavljen je drugi intervju z Eduardom Šiškinom, razvijalcem datotečnega sistema Reiser4.
Za začetek spomnite bralce, kje in za koga delate.
Delam kot glavni arhitekt za shranjevanje pri Huawei Technologies, nemškem raziskovalnem centru. V oddelku za virtualizacijo se ukvarjam z različnimi vidiki shranjevanja podatkov. Moje dejavnosti niso povezane z določenim operacijskim sistemom.
Ali ste trenutno vezani na glavno vejo jedra?
Zelo redko in le, če moj delodajalec to zahteva. Nazadnje pred približno tremi leti sem poslal popravke za povečanje prepustnosti za shranjevanje v skupni rabi na gostiteljih, ki uporabljajo protokol 9p (drugo ime za ta posel je VirtFS). Tukaj je treba poudariti eno pomembno opombo: čeprav se z Linuxom ukvarjam že dolgo, ga nikoli nisem oboževal, se pravi, da »diham enakomerno«, kot pri vsem drugem. Še posebej, če opazim napako, jo lahko opozorim največ enkrat. In da potem nekomu slediš in ga prepričuješ – to se ne bo zgodilo.
Spomnim se, da ste bili nazadnje, pred desetimi leti, precej kritični do stila razvoja jedra. Se je z vašega (ali morda korporativnega) vidika kaj spremenilo, je skupnost postala bolj odzivna ali ne? Če ne, kdo je po vašem mnenju kriv?
Nikoli nisem opazil sprememb na bolje. Glavni problem skupnosti je nadomeščanje znanosti s političnimi tehnologijami, osebnimi odnosi, večinskim mnenjem, populizmom, nasveti »notranjih glasov«, gnilimi kompromisi, karkoli drugega kot znanost. Računalništvo, kakorkoli že kdo reče, je v prvi vrsti eksaktna znanost. In če nekdo začne razglašati lastno vrednost za 2x2, drugačno od 4, pod zastavo "Linux way" ali pod kakšno drugo zastavo, potem to verjetno ne bo prineslo nič drugega kot škode.
Vse težave so predvsem posledica nesposobnosti in neizobraženosti tistih, ki odločajo. Če je vodja nesposoben, ni sposoben sprejeti objektivne, ustrezne odločitve. Če je poleg tega še nekulturen, ne more najti kompetentnega strokovnjaka, ki bi mu pravilno svetoval. Z veliko verjetnostjo bo izbira padla na goljufa, ki govori »na videz pravilne stvari«. Okrog nesposobnih osamljenih voditeljev se vedno razvije pokvarjeno okolje. Poleg tega zgodovina v tem pogledu ne pozna izjem in skupnost je najbolj jasna potrditev tega.
Kako ocenjujete napredek pri razvoju Btrfs? Ali se je ta FS znebil otroških bolezni? Kako ga pozicionirate zase - kot FS "za doma" ali tudi za korporativno uporabo?
Nisem se ga znebil. Vse, kar sem omenil pred 11 leti, je aktualno še danes. Ena od težav z Btrfs, zaradi katere ni primeren za resne potrebe, je problem prostega prostora. Sploh ne govorim o tem, da je uporabnik pozvan, da teče v trgovino po nov disk v situacijah, ko bi kateri koli drug FS pokazal veliko prostega prostora na particiji. Nezmožnost dokončanja operacije na logičnem nosilcu zaradi pomanjkanja prostega prostora tudi ni najslabša stvar. Najslabše pa je, da lahko neprivilegirani uporabnik skoraj vedno, mimo morebitnih diskovnih kvot, v dokaj kratkem času vsem odvzame prosti prostor.
Videti je takole (testirano za jedro Linuxa 5.12). Na sveže nameščenem sistemu se zažene skripta, ki v zanki ustvari datoteke z določenimi imeni v domačem imeniku, vanje zapiše podatke z določenimi odmiki in nato te datoteke izbriše. Po minuti izvajanja tega skripta se ne zgodi nič nenavadnega. Po petih minutah se delež zasedenega prostora na predelni steni rahlo poveča. Po dveh do treh urah doseže 50 % (z začetno vrednostjo 15 %). In po petih ali šestih urah dela se skript zruši z napako »na particiji ni prostega prostora«. Po tem ne morete več zapisati niti datoteke 4K na vašo particijo.
Zgodi se zanimiva situacija: na koncu niste ničesar zapisali na particijo in ves prosti prostor (približno 85%) je nekam izginil. Analiza odseka, ki je podvržen takšnemu napadu, bo razkrila veliko drevesnih vozlišč, ki vsebujejo samo en element (predmet, opremljen s ključem), velik več bajtov. To pomeni, da se je vsebina, ki je prej zasedala 15% prostora na disku, enakomerno "razmazala" po celotni particiji, tako da ni nikamor zapisati nove datoteke, ker je njen ključ večji od vseh obstoječih in prosti blokov na particiji je zmanjkalo.
Poleg tega se vse to zgodi že v osnovni konfiguraciji Btrfs (brez kakršnih koli posnetkov, podvolumenov itd.) in ni pomembno, kako se odločite za shranjevanje teles datotek v ta FS (kot »fragmente« v drevesu ali kot obsege neformatiranih blokov) – končni rezultat bo enak.
Drugih datotečnih sistemov navzgor ne boste mogli izpostaviti takšnemu napadu (ne glede na to, kaj vam rečejo). Vzrok problema sem že zdavnaj razložil: gre za popolno sprevrženost koncepta B-drevesa v Btrfs, ki omogoča njegovo spontano ali namerno degeneracijo. Zlasti pod določenimi obremenitvami bo vaš datotečni sistem nenehno "razpadal" med delovanjem sam, brez zunanje pomoči. Jasno je, da bodo vse vrste "pritiskajočih" procesov v ozadju rešile dan le na posameznih namizjih.
Na kolektivnih strežnikih jih bo napadalec vedno lahko »prehitel«. Sistemski skrbnik sploh ne bo mogel ugotoviti, kdo točno ga je ustrahoval. Najhitrejši način za odpravo te težave v Btrfs je obnovitev strukture navadnega B-drevesa, tj. preoblikovanje formata diska in prepis pomembnih delov kode Btrfs. To bo trajalo 8-10 let, vključno z odpravljanjem napak, pod pogojem, da so razvijalci dosledno upoštevali izvirne članke o ustreznih algoritmih in podatkovnih strukturah ter da niso igrali igre "pokvarjen telefon", kot je običajno (in spodbujano) v "Linuxu". način«.
Tukaj moramo dodati tudi čas, potreben, da razvijalci vse to razumejo. Tukaj postane težje. Vsekakor je bilo 10 let premalo, da bi razumeli. No, do takrat pa ne morete upati na čudež. To se ne bo zgodilo v obliki možnosti namestitve, »za katero vi in jaz nismo vedeli« ali v obliki popravka, ki ga je treba pripraviti »samo stvar posla«. Za vsak tako prenagljen "popravek" bom predstavil nov scenarij degeneracije. B-drevesa so ena mojih najljubših tem in moram reči, da te strukture ne tolerirajo svoboščin pri sebi!
Kako naj postavim Btrfs zase? Kot nekaj, čemur nikakor ne moremo reči datotečni sistem, kaj šele uporabljati. Ker je FS po definiciji podsistem OS, ki je odgovoren za učinkovito upravljanje vira »disk space«, česar v primeru Btrfs ne vidimo. No, predstavljajte si, da ste prišli v trgovino kupit uro, da ne boste zamudili v službo, namesto ure pa so vam prodali električni žar s časovnikom za največ 30 minut. Torej je situacija z Btrfs še slabša.
Pri pregledovanju poštnih seznamov pogosto naletim na trditev, da učinkovito upravljanje s prostorom na disku zaradi cenenosti diskov ni več pomembno. To je popolna neumnost. Brez učinkovitega upravitelja prostora na disku bo OS postal ranljiv in neuporaben. Ne glede na kapaciteto diskov na vašem stroju.
Rad bi prosil za komentar o ukinitvi podpore Btrfs v RHEL.
Tukaj ni kaj posebnega komentirati, vse je zelo jasno. Imeli so ga tudi kot "tehnološki predogled". Torej, nisem šel skozi ta "predogled". Naj ta nalepka ne visi večno! Ne morejo pa lansirati izdelka s pomanjkljivo zasnovo s popolno podporo. RHEL je podjetje, torej predpisana blagovno-denarna razmerja. Red Hat ne more ustrahovati uporabnikov, kot to počnejo na poštnem seznamu Btrfs. Samo predstavljajte si situacijo: stranka, ki je plačala svoj težko prislužen denar za disk in tudi vam za podporo, želi razumeti, kam je šel njegov prostor na disku, potem ko ni ničesar zapisal. Kaj mu boste odgovorili na to?
Nadalje. Stranke Red Hat vključujejo znane velike banke in borze. Predstavljajte si, kaj bi se zgodilo, če bi bili izpostavljeni napadom DoS na podlagi omenjene ranljivosti v Btrfs. Kdo je po vašem mnenju odgovoren za to? Tistim, ki bodo s prstom pokazali na vrstico licence GPL, kjer piše, da avtor za nič ne odgovarja, bom takoj rekel: "skrij!" Red Hat bo odgovoril, in to tako, da se ne bo zdelo dovolj! Vendar vem, da se Red Hat ne sooča s tovrstnimi težavami, glede na njihovo posebej močno ekipo inženirjev za zagotavljanje kakovosti, s katerimi sem imel priložnost tesno sodelovati v svojem času.
Zakaj nekatera podjetja še naprej podpirajo Btrfs v svojih podjetniških izdelkih?
Upoštevajte, da predpona »podjetje« v imenu izdelka ne pomeni veliko. Podjetnost je mera odgovornosti, vgrajena v pogodbeno razmerje s stranko. Poznam samo eno podjetje, ki temelji na GNU/Linuxu - RHEL. Vse ostalo je z mojega vidika samo predstavljeno kot podjetje, ni pa eno. In nenazadnje, če je po nečem povpraševanje, bo vedno tudi ponudba (v našem primeru je to omenjena “podpora”). Povpraševanje je po absolutno vsem, vklj. in neuporabno programsko opremo. Kako se takšno povpraševanje oblikuje in kdo ga spodbuja, je druga tema.
Torej, ne bi delal prehitrih zaključkov, potem ko se govori, da je Facebook na svoje strežnike namestil Btrfs. Poleg tega priporočam, da naslove teh strežnikov skrbno ohranjate v tajnosti zaradi zgornjih razlogov.
Zakaj je bilo zadnje čase vloženega toliko truda v čiščenje kode XFS? Navsezadnje je to sprva datotečni sistem tretje osebe, ext4 pa je že dolgo stabilen in ima kontinuiteto iz prejšnjih enako stabilnih različic. Kakšno zanimanje ima Red Hat za XFS? Ali je smiselno aktivno razvijati dva po namenu podobna datotečna sistema - ext4 in XFS?
Ne spomnim se, kaj je to motiviralo. Povsem mogoče je, da je pobuda prišla s strani strank Red Hat. Spomnim se, da so bile izvedene tovrstne raziskave: na nekaterih datotečnih sistemih od zgoraj je bilo ustvarjeno ogromno število objektov na pogonih višjega cenovnega razreda nove generacije. Glede na rezultate se je XFS obnašal bolje kot ext4. Zato so ga začeli promovirati kot najbolj obetavnega. Vsekakor pa tukaj ne bi iskal nič senzacionalnega.
Pri meni je tako, kot da so šilo zamenjali z milom. Nima smisla razvijati ext4 in XFS. Oba vzporedno in kateri koli od njih na izbiro. Nič dobrega ne bo iz tega. Čeprav so v naravi pogosto situacije, ko je potenciala za rast veliko, prostora za rast pa ni. V tem primeru nastanejo različne bizarno grde novotvorbe, na katere vsi kažejo s prstom ("Oh, poglej, česa vsega ne boš videl v tem življenju!").
Ali menite, da je bilo vprašanje kršitve plasti rešeno (v negativnem smislu) s pojavom šifrirnih funkcij v ext4, F2FS (da ne omenjam RAID v Btrfs)?
Na splošno je uvedba kakršnih koli ravni in odločitev o njihovi nekršitvi običajno stvar politike in tukaj se ne zavezujem komentirati ničesar. Objektivni vidiki kršitve sloja nikogar ne zanimajo, vendar lahko nekatere od njih obravnavamo na primeru kršitve "od zgoraj", in sicer implementacije v FS funkcionalnosti, ki že obstaja na blokovnem sloju. Takšna »kršitev« je upravičena le v redkih izjemah. Za vsak tak primer je treba najprej dokazati dvoje: da je res potrebno in da s tem ne bo škodovalo zasnovi sistema.
Na primer, zrcaljenje, ki je tradicionalno dejavnost za plast blokov, je smiselno izvajati na ravni datotečnega sistema. Iz različnih razlogov. Na diskovnih pogonih se na primer pojavi "tiha" poškodba podatkov (bitna gniloba). To je takrat, ko naprava deluje pravilno, vendar so podatki bloka nepričakovano poškodovani pod vplivom močnega kvanta gama, ki ga oddaja oddaljeni kvazar itd. Najslabše je, če se izkaže, da je ta blok sistemski blok FS (superblok, blok bitne slike, vozlišče pomnilniškega drevesa itd.), ker bo to zagotovo povzročilo paniko jedra.
Upoštevajte, da vas zrcala, ki jih ponuja blokovni sloj (tako imenovani RAID 1), ne bodo rešila te težave. No, res: nekdo bi moral preveriti kontrolne vsote in prebrati repliko v primeru okvare? Poleg tega je smiselno zrcaliti ne samo vse, ampak samo metapodatke. Nekatere pomembne podatke (na primer izvršljive datoteke kritičnih aplikacij) lahko shranite kot metapodatke. V tem primeru prejmejo enaka jamstva za varnost. Varovanje preostalih podatkov je smiselno zaupati drugim podsistemom (morda celo uporabniškim aplikacijam) – za to smo zagotovili vse potrebne pogoje.
Takšna "ekonomična" ogledala imajo pravico do obstoja in jih je mogoče učinkovito organizirati le na ravni datotečnega sistema. V nasprotnem primeru je kršitev plastenja natrpanje podsistema s podvojeno kodo zaradi nekaterih mikroskopskih koristi. Osupljiv primer tega je izvedba RAID-5 z uporabo FS. Takšne rešitve (lastni RAID / LVM v datotečnem sistemu) slednjega ubijajo v arhitekturnem smislu. Tukaj je treba tudi opozoriti, da kršitev plastenja "spravijo na tok" s strani različnih vrst marketinških prevarantov. Ker ni idej, se v podsisteme doda funkcionalnost, ki je že dolgo implementirana na sosednjih ravneh, to se predstavi kot nova izjemno uporabna lastnost in se aktivno potiska.
Reiser4 je bil obtožen kršitve ravni "od spodaj". Na podlagi dejstva, da datotečni sistem ni monoliten, kot vsi drugi, ampak modularen, je bila narejena neutemeljena predpostavka, da počne tisto, kar bi morala delati zgornja raven (VFS).
Ali je mogoče govoriti o smrti ReiserFS v3.6 in na primer JFS? Zadnje čase v jedru niso bili deležni skoraj nobene pozornosti. Ali so zastareli?
Tu moramo opredeliti, kaj pomeni smrt programskega izdelka. Po eni strani se uspešno uporabljajo (navsezadnje so za to ustvarjeni), kar pomeni, da živijo. Po drugi strani pa ne morem govoriti za JFS (ne vem veliko), vendar se ReiserFS (v3) zelo težko prilagaja novim trendom (preverjeno v praksi). To pomeni, da razvijalci v prihodnosti ne bodo pozorni na to, temveč na tiste, ki jih je lažje prilagoditi. S te strani se izkaže, da je, žal, v arhitekturnem smislu mrtev. S konceptom "moralno zastarelega" sploh ne bi manipuliral. Dobro velja na primer za garderobo, ne pa tudi za programske izdelke. V nečem obstaja koncept manjvrednosti in večvrednosti. Absolutno lahko rečem, da je ReserFS v3 zdaj slabši od Reiser4 v vsem, vendar je pri nekaterih vrstah delovne obremenitve boljši od vseh drugih FS-jev navzgor.
Ali veste o razvoju FS Tux3 in HAMMER/HAMMER2 (FS za DragonFly BSD)?
Ja, vemo. Pri Tux3 me je nekoč zanimala tehnologija njihovih posnetkov (t.i. »version pointers«), pri Reiser4 pa bomo najverjetneje ubrali drugo pot. Dolgo sem razmišljal o podpori za posnetke in se še nisem odločil, kako bi jih implementiral za preproste nosilce Reiser4. Dejstvo je, da novodobna tehnika "lenega" referenčnega števca, ki jo predlaga Ohad Rodeh, deluje samo za B-drevesa. Mi jih nimamo. Za tiste podatkovne strukture, ki se uporabljajo v Reiesr4, "leni" števci niso definirani - za njihovo uvedbo je potrebno rešiti določene algoritemske probleme, ki se jih še nihče ni lotil.
Glede na HAMMER: Prebral sem članek ustvarjalca. Ne zanima me. Spet B-drevesa. Ta struktura podatkov je brezupno zastarela. V prejšnjem stoletju smo ga opustili.
Kako ocenjujete naraščajoče povpraševanje po FS-jih omrežnih gruč, kot je CephFS/GlusterFS/itd? Ali to povpraševanje pomeni premik prioritet razvijalcev k omrežnim FS in premalo pozornosti lokalnim FS?
Ja, prišlo je do takšnega premika prioritet. Razvoj lokalnih datotečnih sistemov je stagniral. Žal, narediti nekaj pomembnega za lokalne količine je zdaj precej težko in tega ne zmore vsak. Nihče noče vlagati v njihov razvoj. To je približno enako, kot če bi komercialno organizacijo prosili, naj dodeli denar za matematične raziskave - brez kakršnega koli navdušenja vas bodo vprašali, kako lahko zaslužite na novem izreku. Zdaj je lokalni FS nekaj, kar se čudežno zdi "izven škatle" in "bi moralo vedno delovati", in če ne deluje, povzroči nenaslovljeno godrnjanje, kot je: "Ja, kaj si mislijo!"
Od tod premajhna pozornost do lokalnih FS, čeprav je na tem področju še veliko dela. In ja, vsi so se obrnili na porazdeljeno shranjevanje, ki je zgrajeno na podlagi že obstoječih lokalnih datotečnih sistemov. Zdaj je zelo modno. Besedna zveza »veliki podatki« marsikomu povzroči adrenalin, saj ga povezujejo s konferencami, delavnicami, visokimi plačami itd.
Kako smiselno je načeloma implementirati omrežni datotečni sistem v prostor jedra in ne v uporabniški prostor?
Zelo razumen pristop, ki še ni bil nikjer implementiran. Na splošno je vprašanje, v katerem prostoru naj se implementira omrežni datotečni sistem, »dvorezen meč«. No, poglejmo primer. Odjemalec je podatke posnel na oddaljeni napravi. Padli so v njen predpomnilnik strani v obliki umazanih strani. To je naloga za omrežni datotečni sistem "tanek prehod" v prostoru jedra. Nato vas bo operacijski sistem prej ali slej pozval, da te strani zapišete na disk, da jih sprostite. Nato pride v poštev IO-forwarding (pošiljanje) omrežni FS modul. Določa, na kateri strežniški stroj (strežniško vozlišče) bodo šle te strani.
Nato prevzame omrežni sklad (in, kot vemo, je implementiran v prostor jedra). Nato strežniško vozlišče prejme ta paket s podatki ali metapodatki in ukaže zalednemu modulu za shranjevanje (tj. lokalni FS, ki deluje v prostoru jedra), naj posname vse te stvari. Torej smo zmanjšali vprašanje na to, kje naj delujeta modula »pošiljanje« in »prejemanje«. Če se kateri koli od teh modulov izvaja v uporabniškem prostoru, bo to neizogibno povzročilo preklop konteksta (zaradi potrebe po uporabi storitev jedra). Število takih stikal je odvisno od podrobnosti izvedbe.
Če je takih stikal veliko, se bo prepustnost shranjevanja (zmogljivost V/I) zmanjšala. Če vaš zaledni prostor za shranjevanje sestavljajo počasni diski, ne boste opazili bistvenega padca. Če pa imate hitre diske (SSD, NVRAM ipd.), potem preklapljanje konteksta že postane "ozko grlo" in z varčevanjem pri preklapljanju konteksta lahko bistveno povečate zmogljivost. Standardni način za prihranek denarja je premik modulov v prostor jedra. Ugotovili smo na primer, da premik strežnika 9p iz QEMU v jedro na gostiteljskem računalniku povzroči trikratno povečanje zmogljivosti VirtFS.
To seveda ni omrežni FS, vendar v celoti odraža bistvo stvari. Slaba stran te optimizacije so težave s prenosljivostjo. Za nekatere je lahko slednje kritično. Na primer, GlusterFS sploh nima modulov v jedru. Zahvaljujoč temu zdaj deluje na številnih platformah, vključno z NetBSD.
Katere koncepte bi si lokalni FS-ji lahko izposodili od omrežnih in obratno?
Dandanes imajo omrežni FS-ji praviloma dodatke nad lokalnimi FS-ji, tako da mi ni čisto jasno, kako si lahko kaj izposodiš od slednjih. No, pa res, vzemimo podjetje 4 zaposlenih, v katerem vsak dela po svoje: eden razdeljuje, drugi pošilja, tretji sprejema, četrti skladišči. In vprašanje, kaj si lahko podjetje izposodi od svojega zaposlenega, ki to skladišči, zveni nekako napačno (to, kar bi si lahko izposodilo od njega, že dolgo ima).
Toda lokalni FS-ji se lahko veliko naučijo od omrežnih. Najprej se morate od njih naučiti, kako združevati logične nosilce na visoki ravni. Zdaj t.i »Napredni« lokalni datotečni sistemi združujejo logične nosilce izključno z uporabo tehnologije »navidezne naprave«, izposojene od LVM (ista nalezljiva kršitev slojev, ki je bila prvič implementirana v ZFS). Z drugimi besedami, prevajanje virtualnih naslovov (številk blokov) v realne in nazaj se zgodi na nizki ravni (tj. potem, ko je datotečni sistem izdal I/O zahtevo).
Upoštevajte, da dodajanje in odstranjevanje naprav na logične nosilce (ne zrcala), razporejene na blokovnem sloju, povzroča težave, o katerih dobavitelji takšnih "funkcij" skromno molčijo. Govorim o razdrobljenosti na realnih napravah, ki lahko dosegajo pošastne vrednosti, medtem ko je na virtualni napravi vse v redu. Vendar le malo ljudi zanimajo virtualne naprave: vse zanima, kaj se dogaja na vaših resničnih napravah. Toda ZFS-podobni FS (kot tudi kateri koli FS v povezavi z LVM) delujejo samo z navideznimi diskovnimi napravami (dodelijo naslove navideznih diskov izmed prostih, defragmentirajo te navidezne naprave itd.). In nimajo pojma, kaj se dogaja na resničnih napravah!
Zdaj pa si predstavljajte, da imate na virtualni napravi ničelno razdrobljenost (to pomeni, da tam živi samo en ogromen ekstent), dodate disk svojemu logičnemu nosilcu in nato odstranite še en naključni disk z logičnega nosilca in nato ponovno uravnotežite. In tako velikokrat. Ni si težko predstavljati, da boste na virtualni napravi še vedno živeli v istem obsegu, na resničnih napravah pa ne boste videli nič dobrega.
Najslabše je, da te situacije sploh ne morete popraviti! Edino, kar lahko storite tukaj, je, da zahtevate od datotečnega sistema, da defragmentira virtualno napravo. Povedala pa vam bo, da je tam vse super - obstaja samo en obseg, razdrobljenost je nična in ne more biti boljše! Torej logični nosilci, urejeni na ravni blokov, niso namenjeni ponavljajočemu dodajanju/odstranjevanju naprav. V dobrem smislu morate le enkrat sestaviti logični nosilec na ravni bloka, ga dati datotečnemu sistemu in nato z njim narediti nič drugega.
Poleg tega kombinacija neodvisnih podsistemov FS+LVM ne omogoča upoštevanja različne narave pogonov, iz katerih so združeni logični nosilci. Recimo, da ste sestavili logični nosilec iz HDD in polprevodniških naprav. Toda potem bo prvi zahteval defragmentacijo, drugi pa ne. Pri slednjem morate izdati zahteve za zavrženje, pri prvem pa ne itd. Vendar pa je v tej kombinaciji precej težko dokazati takšno selektivnost.
Upoštevajte, da se po ustvarjanju lastnega LVM v datotečnem sistemu situacija ne izboljša veliko. Še več, s tem pravzaprav onemogočite možnost, da bi ga v prihodnosti kdaj izboljšali. To je zelo slabo. Na istem stroju lahko delujejo različne vrste pogonov. In če jih datotečni sistem ne razlikuje, kdo jih bo?
Druga težava je čakanje na t.i. Datotečni sistemi »Write-Anywhere« (to vključuje tudi Reiser4, če ste med priklopom določili ustrezen transakcijski model). Takšni datotečni sistemi morajo zagotavljati orodja za defragmentacijo, ki so po svoji moči brez primere. In upravitelj glasnosti na nizki ravni tukaj ne pomaga, ampak le ovira. Dejstvo je, da bo s takim upraviteljem vaš FS shranil zemljevid prostih blokov samo ene naprave - virtualne. V skladu s tem lahko defragmentirate samo virtualno napravo. To pomeni, da bo vaš defragmentator dolgo, dolgo deloval na ogromnem enotnem prostoru virtualnih naslovov.
In če imate veliko uporabnikov, ki izvajajo naključne prepise, bo uporaben učinek takšnega defragmentatorja zmanjšan na nič. Vaš sistem se bo neizogibno začel upočasnjevati in morali boste samo prekrižati roke pred razočarajočo diagnozo "pokvarjen dizajn". Več programov za defragmentacijo, ki se izvajajo v istem naslovnem prostoru, se bo samo motilo drug drugega. Povsem druga stvar je, če vzdržujete svoj zemljevid prostih blokov za vsako pravo napravo. To bo učinkovito vzporedilo postopek defragmentacije.
Vendar je to mogoče storiti samo, če imate upravljalnik logičnih nosilcev na visoki ravni. Lokalni datotečni sistemi s takimi upravitelji prej niso obstajali (vsaj jaz ne vem zanje). Samo omrežni datotečni sistemi (na primer GlusterFS) so imeli take upravitelje. Drug zelo pomemben primer je pripomoček za preverjanje integritete nosilca (fsck). Če shranite lasten neodvisen zemljevid prostih blokov za vsak podvolumen, lahko postopek za preverjanje logičnega nosilca učinkovito vzporedite. Z drugimi besedami, logični nosilci z upravitelji na visoki ravni se bolje merijo.
Poleg tega z upravitelji glasnosti na nizki ravni ne boste mogli organizirati popolnih posnetkov. Z datotečnimi sistemi, podobnimi LVM in ZFS, lahko posnamete le lokalne posnetke, ne pa tudi globalnih posnetkov. Lokalni posnetki vam omogočajo, da takoj vrnete samo običajne operacije datotek. In nihče tam ne bo povrnil operacij z logičnimi nosilci (dodajanje/odstranjevanje naprav). Poglejmo si to na primeru. V nekem trenutku, ko imate logični nosilec dveh naprav A in B, ki vsebuje 100 datotek, posnamete posnetek sistema S in nato ustvarite dodatnih sto datotek.
Nato svojemu nosilcu dodate napravo C in končno povrnete sistem na posnetek S. Vprašanje: Koliko datotek in naprav vsebuje vaš logični nosilec po povrnitvi na S? Datotek bo 100, kot ste morda uganili, vendar bodo na voljo 3 naprave - to so iste naprave A, B in C, čeprav sta bili v času, ko je bil posnetek ustvarjen, v sistemu le dve napravi (A in B ). Operacija dodajanja naprave C se ni povrnila nazaj in če zdaj odstranite napravo C iz računalnika, bo to poškodovalo vaše podatke, zato boste morali pred brisanjem najprej izvesti drago operacijo za odstranitev naprave iz logičnega nosilca za ponovno uravnoteženje, ki bo razpršil vse podatke iz naprave C v naprave A in B. Toda če bi vaš FS podpiral globalne posnetke, takšno ponovno uravnoteženje ne bi bilo potrebno in po takojšnjem povrnitvi na S bi lahko varno odstranili napravo C iz računalnika.
Globalni posnetki so torej dobri, ker vam omogočajo, da se izognete dragi odstranitvi (dodajanju) naprave z logičnega nosilca (na logični nosilec) z veliko količino podatkov (seveda, če se spomnite "posnetkati" svoj sistem ob pravem času). Naj vas spomnim, da sta ustvarjanje posnetkov in povrnitev datotečnega sistema nanje takojšnji operaciji. Lahko se pojavi vprašanje: kako je sploh mogoče v trenutku vrniti operacijo na logičnem nosilcu, ki vam je vzela tri dni? Vendar je možno! Pod pogojem, da je vaš datotečni sistem pravilno zasnovan. Idejo o takšnih “3D posnetkih” sem dobil pred tremi leti, lani pa sem to tehniko patentiral.
Naslednja stvar, ki bi se je morali lokalni FS-ji naučiti od omrežnih, je shranjevanje metapodatkov na ločene naprave na enak način, kot jih omrežni FS-ji shranjujejo na ločene stroje (tako imenovani metapodatkovni strežniki). Obstajajo aplikacije, ki delajo predvsem z metapodatki, in te aplikacije je mogoče močno pospešiti s postavitvijo metapodatkov na drage visoko zmogljive naprave za shranjevanje. S kombinacijo FS+LVM ne boste mogli dokazati takšne selektivnosti: LVM ne ve, kaj je v bloku, ki ste mu ga posredovali (podatki tam ali metapodatki).
Ne boste imeli veliko koristi od implementacije lastnega nizkonivojskega LVM v FS v primerjavi s kombinacijo FS+LVM, toda kar lahko naredite zelo dobro, je, da zmešate FS, tako da kasneje postane nemogoče delati z njegovo kodo. ZFS in Btrfs, ki sta hitela z virtualnimi napravami, sta jasna primera, kako kršitev slojev ubija sistem v arhitekturnem smislu. Poleg tega v datotečnem sistemu ni treba zgraditi lastnega nizkonivojskega LVM. Namesto tega morate združiti naprave v logične nosilce na visoki ravni, kot to počnejo nekateri omrežni datotečni sistemi z različnimi napravami (vozlišči za shranjevanje). Res je, da to počnejo gnusno zaradi uporabe slabih algoritmov.
Primera popolnoma groznih algoritmov sta prevajalnik DHT v datotečnem sistemu GlusterFS in tako imenovani zemljevid CRUSH v datotečnem sistemu Ceph. Noben od algoritmov, ki sem jih videl, me ni zadovoljil v smislu enostavnosti in dobre razširljivosti. Tako sem se moral spomniti algebre in si vse izmisliti sam. Leta 2015 sem med eksperimentiranjem s svežnji preko hash funkcij prišel do in patentiral nekaj, kar mi ustreza. Zdaj lahko rečem, da je bil poskus, da bi vse to prenesli v prakso, uspešen. V novem pristopu ne vidim težav z razširljivostjo.
Da, vsak podvolumen bo zahteval ločeno strukturo, kot je superblok v pomnilniku. Je to zelo strašljivo? Na splošno ne vem, kdo bo "zakuhal ocean" in ustvaril logične količine več sto tisoč ali več naprav na enem lokalnem računalniku. Če mi lahko kdo to razloži, bom zelo hvaležen. Medtem je zame to marketinško sranje.
Kako so spremembe v podsistemu blokovne naprave jedra (na primer pojav blk-mq) vplivale na zahteve za implementacijo FS?
Niso imeli nobenega vpliva. Ne vem, kaj bi se zgodilo na blokovnem sloju, zaradi česar bi bilo treba oblikovati nov FS. Interakcijski vmesnik teh podsistemov je zelo slab. S strani gonilnika naj bi na FS vplival le pojav novih tipov pogonov, katerim se bo najprej prilagodil blokovni sloj, nato pa FS (pri reiser4 bo to pomenilo pojav novih vtičnikov).
Ali pojav novih vrst medijev (na primer SMR ali vseprisotnost diskov SSD) pomeni bistveno nove izzive za načrtovanje datotečnega sistema?
ja In to so normalne spodbude za razvoj FS. Izzivi so lahko različni in povsem nepričakovani. Na primer, slišal sem za pogone, pri katerih je hitrost V/I operacije močno odvisna od velikosti podatka in njegovega odmika. V Linuxu, kjer velikost bloka FS ne more preseči velikosti strani, tak pogon privzeto ne bo pokazal vseh svojih zmogljivosti. Vendar, če je vaš datotečni sistem zasnovan pravilno, potem obstaja možnost, da iz njega dobite veliko več.
Koliko ljudi poleg vas trenutno dela s kodo Reiser4?
Manj, kot bi si želel, vendar tudi ne čutim akutnega pomanjkanja sredstev. S hitrostjo razvoja Reiser4 sem več kot zadovoljen. Ne bom "vozil konj" - to ni pravo področje. Tukaj, "če boš vozil bolj tiho, boš šel naprej!" Sodoben datotečni sistem je najbolj zapleten podsistem jedra, katerega napačne načrtovalske odločitve lahko izničijo nadaljnja leta človeškega dela.
S tem, ko ponudim prostovoljcem, da nekaj izvedejo, vedno zagotavljam, da bodo prizadevanja zagotovo pripeljala do pravilnega rezultata, ki je lahko potreben za resne potrebe. Kot razumete, takšnih jamstev ne more biti veliko hkrati. Hkrati ne prenesem "figur", ki brez sramu promovirajo "lastnosti" očitno neuporabne programske opreme, zavajajo na stotine uporabnikov in razvijalcev, hkrati pa sedijo in se smehljajo na vrhovih jedra.
Ali je katero podjetje izrazilo pripravljenost podpreti razvoj Reiser4?
Da, bili so takšni predlogi, vklj. in od glavnega prodajalca. Toda za to sem se moral preseliti v drugo državo. Na žalost nisem več star 30 let, ne morem se odtrgati in tako oditi na prvi žvižg.
Katere funkcije trenutno manjkajo v Reiser4?
Za preproste nosilce ni funkcije »spremeni velikost«, podobne tisti v ReiserFS(v3). Poleg tega operacije datotek z zastavico DIRECT_IO ne bi škodile. Nato bi želel imeti možnost ločiti nosilec v "semantične podvolume", ki nimajo fiksne velikosti in ki jih je mogoče namestiti kot neodvisne nosilce. Te težave so dobre za začetnike, ki se želijo preizkusiti v »pravi stvari«.
In končno, rad bi imel omrežne logične nosilce s preprosto implementacijo in administracijo (sodobni algoritmi to že omogočajo). Kar pa Reiser4 zagotovo ne bo nikoli imel, je RAID-Z, scrubs, predpomnilniki prostega prostora, 128-bitne spremenljivke in ostale marketinške neumnosti, ki so nastale ob pomanjkanju idej med razvijalci nekaterih datotečnih sistemov.
Ali je mogoče vse, kar je potrebno, implementirati z vtičniki?
Če govorimo samo o vmesnikih in vtičnikih (modulih), ki jih implementirajo, potem ne vse. Če pa na teh vmesnikih uvedeš tudi relacije, potem boš med drugim imel koncepte višjih polimorfizmov, s katerimi se že lahko znajdeš. Predstavljajte si, da ste hipotetično zamrznili objektno usmerjen izvajalni sistem, spremenili vrednost kazalca navodil, da kaže na drug vtičnik, ki implementira isti vmesnik X, in nato odmrznili sistem, tako da se nadaljuje z izvajanjem.
Če končni uporabnik ne opazi takšne "zamenjave", potem pravimo, da ima sistem polimorfizem ničelnega reda v vmesniku X (ali pa je sistem heterogen v vmesniku X, kar je isto). Če zdaj nimate samo nabora vmesnikov, ampak imate na njih tudi odnose (graf vmesnika), potem lahko uvedete polimorfizme višjih redov, ki bodo označevali heterogenost sistema že v "soseski" katerega koli vmesnika. Tako klasifikacijo sem uvedel že zdavnaj, a se žal nikoli ni zgodila.
Torej, s pomočjo vtičnikov in takšnih višjih polimorfizmov lahko opišete katero koli znano lastnost, pa tudi »predvidite« tiste, ki še niso bile niti omenjene. Tega nisem mogel strogo dokazati, a tudi protiprimera še ne poznam. Na splošno me je to vprašanje spomnilo na »Erlangenski program« Felixa Kleina. Nekoč je poskušal celotno geometrijo predstaviti kot vejo algebre (natančneje teorije skupin).
Zdaj pa k glavnemu vprašanju - kako gredo stvari s promocijo Reiser4 v glavno jedro? Ali so bile objavljene kakšne objave o arhitekturi tega datotečnega sistema, o katerem ste govorili v zadnjem intervjuju? Kako relevantno je to vprašanje z vašega vidika?
Na splošno prosimo za vključitev v glavno vejo že tri leta. Reiserjev zadnji komentar v javni temi, kjer je bila podana zahteva za umik, je ostal brez odgovora. Torej vsa nadaljnja vprašanja niso za nas. Osebno ne razumem, zakaj se moramo "združiti" v določen operacijski sistem. Na Linuxu se svetloba ni stekla kot klin. Torej obstaja ločeno skladišče, v katerem bo več vej za različne operacijske sisteme. Kdor ga potrebuje, lahko klonira ustrezen port in dela z njim kar hoče (seveda v okviru licence). No, če kdo tega ne potrebuje, potem to ni moj problem. Na tej točki predlagam, da se obravnava vprašanje "napredovanja v glavno jedro Linuxa" kot rešeno.
Publikacije o arhitekturi FS so pomembne, vendar sem zaenkrat našel čas le za svoje nove rezultate, ki se mi zdijo bolj prioritetni. Druga stvar je, da sem matematik in v matematiki je vsaka publikacija povzetek izrekov in njihovih dokazov. Objava karkoli tam brez dokazov je znak slabega okusa. Če bom kakšno trditev o arhitekturi FS temeljito dokazal ali ovrgel, potem bodo rezultat taki kupi, da bo kar težko priti skozi. Kdo ga potrebuje? Verjetno zato vse še naprej ostaja v stari obliki - izvorna koda in komentarji k njej.
Kaj je novega v Reiser4 v zadnjih nekaj letih?
Dolgo pričakovana stabilnost se je končno uresničila. Ena zadnjih, ki se je pojavila, je bila napaka, ki je vodila do imenikov, ki jih ni mogoče izbrisati. Težava je bila v tem, da se je pojavil samo v ozadju trkov zgoščenih imen in z določeno lokacijo zapisov imenika v drevesnem vozlišču. Vendar še vedno ne morem priporočiti Reiser4 za proizvodnjo: za to morate opraviti nekaj dela z aktivno interakcijo s skrbniki proizvodnega sistema.
Končno nam je uspelo uresničiti našo dolgoletno idejo - drugačne transakcijske modele. Prej je Reiser4 izvajal samo en trdo kodiran Macdonald-Reiserjev model. To je povzročilo težave pri oblikovanju. Zlasti posnetki v takem transakcijskem modelu niso mogoči – pokvari jih atomska komponenta, imenovana »OVERWRITE SET«. Reiser4 trenutno podpira tri modele transakcij. V enem izmed njih (Write-Anywhere) atomska komponenta OVERWRITE SET vključuje samo sistemske strani (slike bitnih slik diska ipd.), ki jih ni mogoče “fotografirati” (problem kokoš in jajce).
Tako je zdaj mogoče slike realizirati na najboljši možni način. V drugem transakcijskem modelu gredo vse spremenjene strani samo v OVERWRITE SET (to je v bistvu čisto beleženje). Ta model je za tiste, ki so se pritoževali nad hitro razdrobljenostjo particij Reiser4. Zdaj v tem modelu vaša particija ne bo fragmentirana nič hitreje kot z ReiserFS (v3). Vsi trije obstoječi modeli z nekaterimi zadržki zagotavljajo atomičnost operacij, uporabni pa so lahko tudi modeli z izgubo atomičnosti in ohranjanjem samo celovitosti odseka. Takšni modeli so lahko uporabni za vse vrste aplikacij (baze podatkov itd.), ki so nekatere od teh funkcij že prevzele. Te modele je zelo enostavno dodati v Reiser4, vendar tega nisem naredil, ker me nihče ni vprašal in osebno tega ne potrebujem.
Pojavile so se kontrolne vsote metapodatkov in pred kratkim sem jih dopolnil z »ekonomičnimi« zrcali (še vedno nestabilen material). Če kontrolna vsota katerega koli bloka ne uspe, Reiser4 takoj prebere ustrezen blok iz naprave replike. Upoštevajte, da ZFS in Btrfs tega ne moreta: zasnova tega ne dovoljuje. Tam morate zagnati poseben postopek skeniranja v ozadju, imenovan »čiščenje«, in počakati, da pride do problematičnega bloka. Programerji takšne dogodke figurativno imenujejo "bergle".
In končno so se pojavili heterogeni logični nosilci, ki ponujajo vse, česar ZFS, Btrfs, blokovni sloj, pa tudi kombinacije FS+LVM načeloma ne morejo zagotoviti - vzporedno skaliranje, O(1) dodeljevalec diskovnih naslovov, pregledno selitev podatkov med podvolumeni. Slednji ima tudi uporabniški vmesnik. Zdaj lahko preprosto premaknete najbolj vroče podatke na najzmogljivejši disk na vašem nosilcu.
Poleg tega je možno morebitne umazane strani nujno splakniti na tak pogon, s čimer se občutno pospešijo aplikacije, ki pogosto kličejo fsync(2). Opažam, da funkcionalnost blokovne plasti, imenovana bcache, sploh ne zagotavlja takšne svobode delovanja. Novi logični nosilci temeljijo na mojih algoritmih (obstajajo ustrezni patenti). Programska oprema je že precej stabilna, povsem možno jo je preizkusiti, izmeriti zmogljivost itd. Edina neprijetnost je, da morate trenutno ročno posodobiti konfiguracijo glasnosti in jo nekam shraniti.
Doslej mi je uspelo uresničiti svoje ideje za 10 odstotkov, uspelo pa mi je tisto, kar se mi je zdelo najtežje - povezovanje logičnih nosilcev s proceduro flash, ki izvaja vsa odložena dejanja v reiser4. Vse to je še vedno v poskusni veji »format41«.
Ali Reiser4 opravi xftests?
Vsaj meni je bilo, ko sem pripravljal zadnjo objavo.
Ali je načeloma možno narediti Reiser4 omrežni (cluster) FS z uporabo vtičnikov?
Možno je in celo potrebno! Če ustvarite omrežno datoteko na podlagi pravilno zasnovanega lokalnega datotečnega sistema, bo rezultat zelo impresiven! V sodobnih omrežnih FS-jih nisem zadovoljen s prisotnostjo zaledne ravni shranjevanja, ki je implementirana s katerim koli lokalnim FS-jem. Obstoj te ravni je popolnoma neupravičen. Omrežni FS mora neposredno komunicirati s plastjo blokov in ne sme zahtevati od lokalnega FS, da ustvari druge storitvene datoteke!
Na splošno je delitev datotečnih sistemov na lokalne in omrežne od hudobnega. Nastala je zaradi nepopolnosti algoritmov, ki so bili uporabljeni pred tridesetimi leti in namesto katerih še ni bilo predlagano nič. To je tudi razlog za pojav množice nepotrebnih programskih komponent (različne storitve itd.). V dobrem smislu bi moral biti na vsakem stroju nameščen samo en FS v obliki modula jedra in nabora uporabniških pripomočkov - vozlišče gruče. Ta FS je tako lokalni kot omrežni. In nič več!
Če nič ne deluje z Reiser4 v Linuxu, bi rad ponudil FS za FreeBSD (citat iz prejšnjega intervjuja: »...FreeBSD ... ima akademske korenine ... In to pomeni, da z veliko verjetnostjo bo našel skupni jezik z razvijalci«) ?
Torej, kot smo pravkar izvedeli, se je z Linuxom že vse odlično izšlo: zanj obstaja ločena delujoča vrata Reiser4 v obliki glavne veje našega skladišča. Nisem pozabil na FreeBSD! Ponudba! Pripravljen sem tesno sodelovati s tistimi, ki dobro poznajo notranjost FreeBSD. Mimogrede: pri njihovi skupnosti mi je zelo všeč to, da tam odloča posodobljen svet neodvisnih strokovnjakov, kar nima nobene zveze z vladnim zavajanjem enega stalnega človeka.
Kako ocenjujete skupnost uporabnikov Linuxa danes? Je postalo bolj "pop"?
Glede na naravo mojega dela to kar težko ocenim. Večinoma uporabniki prihajajo k meni s poročili o napakah in zahtevami za popravek razdelka. Uporabniki kot uporabniki. Nekateri so bolj spretni, drugi manj. Vsi so obravnavani enako. No, če uporabnik ignorira moja navodila, se opravičujem: vrstni red ignoriranja bo vpisan tudi z moje strani.
Ali je mogoče napovedati razvoj datotečnih sistemov za naslednjih pet do deset let? Kateri so po vašem mnenju glavni izzivi, s katerimi se lahko soočijo razvijalci FS?
Da, takšne napovedi ni težko narediti. Dolgo časa ni bilo razvoja datotečnih sistemov navzgor. Ustvarja se le videz takega. Razvijalci lokalnih datotečnih sistemov so naleteli na težave, povezane s slabo zasnovo. Tukaj je treba narediti opozorilo. Tako imenovanega "shranjevanja", "lizanja" in prenosa kode ne štejem za razvoj in razvoj. In nesporazuma, imenovanega "Btrfs", ne uvrščam med razvoj zaradi razlogov, ki sem jih že pojasnil.
Vsak popravek samo poslabša svoje težave. No. in vedno obstajajo različne vrste "evangelistov", ki jim "vse deluje". V bistvu so to dijaki in študenti, ki izpuščajo predavanja. Samo predstavljajte si: njemu gre, profesorju pa ne. Kakšen adrenalin je to! Z mojega vidika največjo škodo povzročajo »obrtniki«, ki so hiteli z navdušenjem »šraufati« čudovite funkcije Btrfs na najrazličnejše plasti, kot so systemd, docker itd. - to že spominja na metastaze.
Poskusimo zdaj narediti napoved za pet do deset let. Na kratko sem že naštel, kaj bomo počeli v Reiser4. Glavni izziv za lokalne razvijalce FS od zgoraj bo (ja, to je že postalo) nezmožnost opravljanja dostojnega dela za plačo. Brez kakršnih koli idej na področju shranjevanja podatkov bodo še naprej poskušali krpati te neposrečene VFS, XFS in ext4. Situacija z VFS je na tem ozadju videti še posebej komična, spominja na blazno modernizacijo restavracije, v kateri ni kuharjev in jih ni pričakovati.
Zdaj koda VFS brez kakršnih koli pogojev zaklene več pomnilniških strani hkrati in povabi osnovni FS, da deluje na njih. To je bilo uvedeno za izboljšanje zmogljivosti Ext4 pri operacijah brisanja, a kot je lahko razumeti, je takšno sočasno zaklepanje popolnoma nezdružljivo z naprednimi modeli transakcij. To pomeni, da ne boste mogli preprosto dodati podpore za neki pametni datotečni sistem v jedru. Ne vem, kakšna je situacija na drugih področjih Linuxa, toda kar zadeva datotečne sisteme, kakršen koli razvoj tukaj verjetno ne bo združljiv s politiko, ki jo Torvalds izvaja v praksi (akademski projekti so izločeni, prevaranti, ki nimajo pojma, kaj je B-drevo, izdajajo se neskončni krediti zaupanja). Zato je bila zastavljena smer počasnega propadanja. Seveda bodo na vso moč poskušali to predstaviti kot "razvoj".
Nadalje se bodo "skrbniki" datotečnih sistemov, zavedajoč se, da samo s "shrambo" ne boste veliko zaslužili, preizkusili v donosnejšem poslu. To so praviloma porazdeljeni datotečni sistemi in virtualizacija. Morda bodo modni ZFS prenesli še kam drugam, kjer ga še ni. Toda, tako kot vsi FS od zgoraj, spominja na novoletno jelko: če lahko na vrh obesiš še nekaj malenkosti, potem ne moreš globlje. Priznam, da je na ZFS mogoče zgraditi resen podjetniški sistem, a ker zdaj razpravljamo o prihodnosti, lahko samo žalostno ugotovim, da je ZFS v tem pogledu brezupen: fantje so s svojimi virtualnimi napravami prekinili kisik zase in za prihodnje generacije za nadaljnji razvoj. ZFS je preteklost. In ext4 in XFS sploh nista predvčerajšnjim.
Ločeno je treba omeniti senzacionalni koncept "datotečnega sistema Linux naslednje generacije". To je popolnoma političen in marketinški projekt, ustvarjen za priložnost, tako rekoč, "pripeti prihodnost datotečnih sistemov" v Linuxu za določene znake. Dejstvo je, da je bil Linux včasih »samo za zabavo«. Zdaj pa je predvsem stroj za ustvarjanje denarja. Narejeni so na vse mogoče. Na primer, zelo težko je ustvariti dober programski izdelek, vendar so pametni »razvijalci« že dolgo ugotovili, da se sploh ni treba naprezati: uspešno lahko prodajate neobstoječo programsko opremo, ki je bila napovedana in promovirana v vseh vrstah javnosti. dogodki - glavna stvar je, da morajo diapozitivi predstavitve vsebovati več "funkcij".
Datotečni sistemi so kot nalašč za to, saj lahko varno barantate deset let za rezultat. No, če se kdo kasneje pritožuje nad pomanjkanjem tega rezultata, potem preprosto ne razume ničesar o datotečnih sistemih! To spominja na finančno piramido: na vrhu so pustolovci, ki so zapletli to zmešnjavo, in tistih nekaj, ki so imeli »srečo«: »odtegnili so dividende«, tj. prejemali denar za razvoj, dobili dobro plačano službo menedžerjev, se »pokazovali« na konferencah itd.
Sledijo tisti, ki nimajo sreče: šteli bodo izgube, se ukvarjali s posledicami uvedbe neuporabnega programskega izdelka v proizvodnjo itd. Teh je veliko več. No, na dnu piramide je ogromna množica razvijalcev, ki "žagajo" neuporabno kodo. Ti so največji poraženci, saj izgubljenega časa ni mogoče vrniti. Takšne piramide so izjemno koristne za Torvaldsa in njegove sodelavce. In več kot je teh piramid, bolje je za njih. Za hranjenje takšnih piramid lahko v jedro vzamemo karkoli. Seveda v javnosti govorijo nasprotno. Ampak ne sodim po besedah, ampak po dejanjih.
Torej je "prihodnost datotečnih sistemov v Linuxu" še ena zelo promovirana, a komaj uporabna programska oprema. Za Btrfs bo z veliko verjetnostjo mesto takšne »prihodnosti« zasedel Bcachefs, ki je še en poskus prekrižanja blokovne plasti Linuxa z datotečnim sistemom (slab primer je nalezljiv). In kar je značilno: obstajajo enake težave kot v Btrfs. Dolgo sem sumil na to, potem pa se nekako nisem mogel upreti in pogledal v kodo - res je!
Avtorji Bcachefs in Btrfs so pri ustvarjanju svojega FS aktivno uporabljali vire drugih ljudi, o njih pa malo razumeli. Situacija zelo spominja na otroško igro "pokvarjen telefon". In približno si lahko predstavljam, kako bo ta koda vključena v jedro. Pravzaprav nihče ne bo videl "grabelj" (kasneje bodo vsi stopili nanje). Po številnih prepirih o slogu kode, obtožbah o neobstoječih kršitvah itd., Bo narejen sklep o "zvestobi" avtorja, kako dobro "interagira" z drugimi razvijalci in kako uspešno lahko vse to nato prodati korporacijam.
Končni rezultat ne bo nikogar zanimal. Pred dvajsetimi leti bi me morda zanimalo, zdaj pa se vprašanja postavljajo drugače: ali bo to mogoče spodbuditi, da bodo določeni ljudje v naslednjih desetih letih zaposleni. In, žal, ni običajno, da bi se spraševali o končnem rezultatu.
Na splošno vam močno odsvetujem, da začnete izumljati svoj datotečni sistem od začetka. Ker tudi znatni finančni vložki ne bodo dovolj, da bi čez deset let dobili nekaj konkurenčnega. Seveda govorim o resnih projektih in ne o tistih, ki so namenjeni "stlačenju" v jedro. Zato je bolj učinkovit način izražanja, da se pridružite resničnemu razvoju, kot smo mi. To seveda ni lahko storiti - a tako je pri vsakem projektu na visoki ravni.
Najprej boste morali samostojno premagati težavo, ki jo bom ponudil. Nato bom, prepričan o resnosti vaših namenov, začel pomagati. Tradicionalno uporabljamo le lasten razvoj. Izjema so algoritmi stiskanja in nekatere zgoščevalne funkcije. Ne pošiljamo razvijalcev na potovanja na konference in potem ne sedimo in kombiniramo idej drugih ljudi (»mogoče kaj bo«), kot je običajno v večini startupov.
Vse algoritme razvijamo sami. Trenutno me zanimajo algebraični in kombinatorični vidiki znanosti o shranjevanju podatkov. Predvsem končna polja, asimptotika, dokaz neenakosti. Delo je tudi za običajne programerje, vendar vas moram takoj opozoriti: vsi predlogi, da "poglejte drug FS in naredite enako", so prezrti. Tja bodo šli tudi popravki, namenjeni tesnejši integraciji z Linuxom prek VFS.
Grabelj torej nimamo, imamo pa razumevanje, kam se moramo premakniti, in verjamemo, da je ta smer prava. To razumevanje ni prišlo v obliki mane iz nebes. Naj vas spomnim, da imamo za seboj 29 let razvojnih izkušenj, dva datotečna sistema, napisana iz nič. In enako število pripomočkov za obnovitev podatkov. In to je veliko!
Vir: opennet.ru