Objavljen je drugi intervju s Eduardom Šiškinom, programerom datotečnog sustava Reiser4.
Za početak podsjetite čitatelje gdje i za koga radite.
Radim kao glavni arhitekt za pohranu u Huawei Technologies, njemačkom istraživačkom centru. U odjelu virtualizacije bavim se raznim aspektima pohrane podataka. Moje aktivnosti nisu vezane uz određeni operativni sustav.
Jeste li se trenutno posvetili glavnoj grani kernela?
Vrlo rijetko i samo ako moj poslodavac to zahtijeva. Posljednji put prije otprilike tri godine poslao sam zakrpe za povećanje propusnosti za pohranu koja se dijeli na hostovima koristeći 9p protokol (drugi naziv za ovaj posao je VirtFS). Ovdje valja napomenuti jednu važnu napomenu: iako već dugo radim s Linuxom, nikad nisam bio njegov fan, odnosno “dišem ravnomjerno”, kao i sa svim ostalim. Konkretno, ako primijetim nedostatak, mogu ga istaknuti najviše jednom. A da onda nekoga pratiš i nagovaraš – to se neće dogoditi.
Sjećam se da ste prošli put, prije deset godina, bili prilično kritični prema stilu razvoja kernela. S vaše (ili možda korporativne) točke gledišta, je li se nešto promijenilo, je li zajednica postala osjetljivija ili ne? Ako nije, što mislite tko je kriv?
Nikad nisam vidio promjene na bolje. Glavni problem zajednice je zamjena znanosti političkim tehnologijama, osobni odnosi, mišljenje većine, populizam, savjeti “unutarnjih glasova”, truli kompromisi, sve osim znanosti. Informatika je, kako god se govorilo, prije svega egzaktna znanost. A ako netko počne proklamirati vlastitu vrijednost za 2x2, različitu od 4, pod zastavom “Linux way” ili pod nekom drugom zastavom, onda to vjerojatno neće donijeti ništa osim štete.
Sve nevolje su prvenstveno zbog nestručnosti i neobrazovanosti onih koji odlučuju. Ako je menadžer nekompetentan, on nije u stanju donijeti objektivnu, adekvatnu odluku. Ako je uz to još i nekulturan, ne može pronaći kompetentnog stručnjaka koji će mu dati pravi savjet. S velikom vjerojatnošću izbor će pasti na prevaranta koji govori “naizgled točne stvari”. Korumpirano okruženje uvijek se razvija oko nesposobnih usamljenih vođa. Štoviše, povijest u tom pogledu ne poznaje iznimke, a zajednica je tome najjasnija potvrda.
Kako ocjenjujete napredak u razvoju Btrfs-a? Je li ovaj FS riješio dječje bolesti? Kako ga pozicionirate za sebe - kao FS "za dom" ili i za korporativnu upotrebu?
Nisam ga se riješio. Sve što sam spomenuo prije 11 godina aktualno je i danas. Jedan od problema s Btrfs-om koji ga čini neprikladnim za ozbiljne potrebe je problem slobodnog prostora. Da i ne govorim o tome da se od korisnika traži da otrči u trgovinu po novi disk u situacijama kada bi bilo koji drugi FS pokazao puno slobodnog prostora na particiji. Nemogućnost dovršetka operacije na logičkom volumenu zbog nedostatka slobodnog prostora također nije najgora stvar. Najgore je što neprivilegirani korisnik može gotovo uvijek, zaobilazeći bilo kakve diskovne kvote, svima oduzeti slobodan prostor u prilično kratkom vremenu.
Izgleda ovako (testirano za Linux kernel 5.12). Na svježe instaliranom sustavu pokreće se skripta koja u petlji stvara datoteke s određenim nazivima u početnom direktoriju, upisuje podatke u njih s određenim pomacima, a zatim briše te datoteke. Nakon minute pokretanja ove skripte ne događa se ništa neobično. Nakon pet minuta, udio zauzetog prostora na pregradi lagano se povećava. Nakon dva do tri sata dostiže 50% (s početnom vrijednošću od 15%). I nakon pet ili šest sati rada, skripta se ruši s pogreškom "nema slobodnog prostora na particiji." Nakon ovoga više ne možete zapisati čak ni 4K datoteku na svoju particiju.
Dogodila se zanimljiva situacija: na kraju niste ništa napisali na particiju, a sav slobodni prostor (oko 85%) je negdje nestao. Analiza dijela podložnog takvom napadu otkrit će mnogo čvorova stabla koji sadrže samo jednu stavku (objekt opremljen ključem), veličine nekoliko bajtova. Odnosno, sadržaj koji je prethodno zauzimao 15% diskovnog prostora pokazao se ravnomjerno "razmazan" po cijeloj particiji tako da nema mjesta za pisanje nove datoteke, jer je njen ključ veći od svih postojećih, a besplatni blokova na particiji je ponestalo.
Štoviše, sve se to događa već na osnovnoj Btrfs konfiguraciji (bez ikakvih snimaka, podvolumena itd.), i nije važno kako odlučite pohraniti tijela datoteka u taj FS (kao “fragmente” u stablu ili kao ekstente neformatiranih blokova) - krajnji rezultat će biti isti.
Nećete moći podvrgnuti druge uzvodne datotečne sustave takvom napadu (bez obzira što vam rekli). Uzrok problema sam davno objasnio: radi se o potpunoj izopačenosti koncepta B-stabla u Btrfs-u, zbog čega se može spontano ili namjerno izroditi. Konkretno, pod određenim opterećenjima, vaš datotečni sustav će se stalno "raspadati" tijekom rada sam, bez vanjske pomoći. Jasno je da će sve vrste "pritiska" pozadinskih procesa spasiti dan samo na pojedinačnim radnim površinama.
Na kolektivnim poslužiteljima, napadač će ih uvijek moći "preduhitriti". Sistemski administrator neće moći ni utvrditi tko ga je točno maltretirao. Najbrži način za rješavanje ovog problema u Btrfsu je vraćanje strukture regularnog B-stabla, tj. redizajn formata diska i ponovno pisanje značajnih dijelova Btrfs koda. To će trajati 8-10 godina, uključujući otklanjanje pogrešaka, pod uvjetom da su programeri strogo slijedili izvorne članke o relevantnim algoritmima i strukturama podataka i da nisu igrali igru "pokvarenog telefona", kao što je uobičajeno (i ohrabreno) u "Linux put".
Tu treba dodati i vrijeme potrebno programerima da sve ovo shvate. Ovdje postaje još teže. U svakom slučaju, 10 godina im nije bilo dovoljno da shvate. Pa, do tada se ne možete nadati čudu. To se neće dogoditi u obliku opcije montiranja "za koju vi i ja nismo znali" ili u obliku zakrpe koju treba pripremiti "samo stvar posla". Za svaki takav ishitreni "popravak" iznijet ću novi scenarij degeneracije. B-stabla su jedna od mojih omiljenih tema, a moram reći da te strukture ne toleriraju slobode same sa sobom!
Kako da pozicioniram Btrfs za sebe? Kao nešto što se apsolutno ne može nazvati datotečnim sustavom, a kamoli koristiti. Jer, po definiciji, FS je OS podsustav odgovoran za učinkovito upravljanje resursom “disk space”, što ne vidimo u slučaju Btrfs. Pa zamislite da ste došli u dućan kupiti sat kako ne biste zakasnili na posao, a umjesto sata prodali su vam električni roštilj s timerom za maksimalno 30 minuta. Dakle, situacija s Btrfs je još gora.
Pregledavajući mailing liste, često naiđem na tvrdnju da učinkovito upravljanje prostorom na disku više nije relevantno zbog jeftinosti diskova. Ovo je potpuna besmislica. Bez učinkovitog upravitelja prostora na disku, OS će postati ranjiv i neupotrebljiv. Bez obzira na kapacitet diskova na vašem stroju.
Želio bih zamoliti za komentar o ukidanju Btrfs podrške u RHEL-u.
Nema se tu što posebno komentirati, sve je vrlo jasno. Imali su ga i kao "tehnološki pregled". Dakle, nisam prošao kroz ovaj "pregled". Ne dopustite da ova etiketa zauvijek visi! Ali oni ne mogu lansirati proizvod s manjkavim dizajnom uz punu podršku. RHEL je poduzeće, odnosno propisani robno-novčani odnosi. Red Hat ne može maltretirati korisnike kao što to čine na Btrfs mailing listi. Zamislite samo situaciju: klijent koji je platio svoj teško zarađeni novac za disk i vama za podršku, želi razumjeti gdje mu je nestao prostor na disku nakon što nije ništa zapisao. Što ćete mu odgovoriti na ovo?
Unaprijediti. Klijenti Red Hata uključuju poznate velike banke i mjenjačnice. Zamislite što bi se dogodilo da su podvrgnuti DoS napadima na temelju spomenute ranjivosti u Btrfsu. Što mislite tko je za to odgovoran? Onima koji će uprijeti prstom u redak GPL licence, gdje piše da autor ni za što ne odgovara, odmah ću reći: "sakrij to!" Red Hat će odgovoriti, i to tako da se neće činiti dovoljno! Ali znam da se Red Hat ne suočava s ovakvim problemom, s obzirom na njihov posebno jak tim QA inženjera s kojima sam svojedobno imao priliku blisko surađivati.
Zašto neke tvrtke nastavljaju podržavati Btrfs u svojim poslovnim proizvodima?
Imajte na umu da prefiks "poduzeće" u nazivu proizvoda ne znači mnogo. Poduzetnost je mjera odgovornosti ugrađena u ugovorni odnos s klijentom. Znam samo za jedno poduzeće temeljeno na GNU/Linuxu - RHEL. Sve ostalo se, s moje strane, samo predstavlja kao poduzeće, ali nije. I na kraju, ako za nečim postoji potražnja, onda će uvijek biti i ponuda (u našem slučaju to je spomenuta “support”). Postoji potražnja za apsolutno svime, uklj. i neupotrebljiv softver. Kako se takva potražnja formira i tko je potiče, druga je tema.
Dakle, ne bih donosio nikakve zaključke nakon što se priča da je Facebook postavio Btrfs na svoje poslužitelje. Štoviše, preporučio bih da pažljivo čuvate adrese tih poslužitelja u tajnosti iz gore navedenih razloga.
Zašto je u posljednje vrijeme toliko truda uloženo u čišćenje XFS koda? Uostalom, u početku je ovo datotečni sustav treće strane, a ext4 je stabilan već duže vrijeme i ima kontinuitet od prethodnih jednako stabilnih verzija. Kakav interes Red Hat ima za XFS? Ima li smisla aktivno razvijati dva datotečna sustava slične namjene - ext4 i XFS?
Ne sjećam se što je to motiviralo. Sasvim je moguće da je inicijativa došla od klijenata Red Hata. Sjećam se da je istraživanje ove vrste provedeno: na nekim datotečnim sustavima od gore, stvoren je ogroman broj objekata na high-end diskovima nove generacije. Prema rezultatima, XFS se ponašao bolje od ext4. Tako su ga počeli promovirati kao najperspektivniji. U svakom slučaju, ne bih tu tražio ništa senzacionalno.
Za mene kao da su šilo zamijenili sapunom. Nema smisla razvijati ext4 i XFS. Oba paralelno i bilo koji od njih na izbor. Ništa dobro neće proizaći iz ovoga. Iako, u prirodi često postoje situacije kada ima puno potencijala za rast, ali nema prostora za rast. U tom slučaju nastaju razne bizarno ružne novotvorine na koje svi upiru prstom ("O, vidi, što sve nećeš vidjeti u ovom životu!").
Mislite li da je pitanje kršenja slojeva riješeno (u negativnom smislu) dolaskom funkcija enkripcije u ext4, F2FS (da ne spominjemo RAID u Btrfs)?
Općenito, uvođenje bilo kojih razina i donošenje odluke o njihovom nekršenju obično je stvar politike i ne obvezujem se komentirati ništa ovdje. Objektivni aspekti kršenja slojeva nikoga malo zanimaju, ali možemo razmotriti neke od njih koristeći primjer kršenja "odozgo", naime, implementaciju u FS funkcionalnosti koja već postoji na blok sloju. Takvo “kršenje” opravdano je uz samo rijetke iznimke. Za svaki takav slučaj prvo morate dokazati dvije stvari: da je stvarno potreban i da time neće biti oštećen dizajn sustava.
Na primjer, zrcaljenje, koje je tradicionalno bilo aktivnost za blok sloj, ima smisla implementirati na razini datotečnog sustava. Iz različitih razloga. Na primjer, "tiho" oštećenje podataka (bit rot) događa se na diskovnim pogonima. To je kada uređaj radi ispravno, ali su blokovi podataka neočekivano oštećeni pod utjecajem jakog gama kvanta koji emitira udaljeni kvazar itd. Najgora stvar je ako se ovaj blok pokaže kao blok FS sustava (superblok, bitmap blok, čvor stabla pohrane itd.), jer će to sigurno dovesti do kernel panike.
Imajte na umu da vas zrcala koja nudi blok sloj (tzv. RAID 1) neće spasiti od ovog problema. Pa, stvarno: netko bi trebao provjeriti kontrolne zbrojeve i pročitati repliku u slučaju kvara? Osim toga, ima smisla zrcaliti ne samo sve, već samo metapodatke. Neki važni podaci (na primjer, izvršne datoteke kritičnih aplikacija) mogu se pohraniti kao metapodaci. U tom slučaju dobivaju ista jamstva sigurnosti. Zaštitu preostalih podataka ima smisla povjeriti drugim podsustavima (možda i korisničkim aplikacijama) – za to smo osigurali sve potrebne uvjete.
Takva "ekonomična" ogledala imaju pravo postojati i mogu se učinkovito organizirati samo na razini datotečnog sustava. U suprotnom, kršenje slojevitosti zatrpava podsustav dupliciranim kodom radi nekih mikroskopskih prednosti. Zapanjujući primjer ovoga je implementacija RAID-5 pomoću FS-a. Takva rješenja (vlastiti RAID/LVM u datotečnom sustavu) ubijaju potonje u arhitektonskom smislu. Ovdje također treba napomenuti da kršenje slojevitosti "stavljaju na stream" razne vrste marketinških prevaranata. U nedostatku bilo kakvih ideja, u podsustave se dodaje funkcionalnost koja je odavno implementirana na susjednim razinama, to se predstavlja kao nova izuzetno korisna značajka i aktivno se forsira.
Reiser4 je optužen za kršenje razina “odozdo”. Na temelju činjenice da datotečni sustav nije monolitan, kao svi ostali, već modularan, napravljena je neutemeljena pretpostavka da radi ono što bi trebala raditi razina iznad (VFS).
Može li se govoriti o smrti ReiserFS v3.6 i npr. JFS-a? U posljednje vrijeme gotovo im se ne posvećuje pozornost u jezgri. Jesu li zastarjeli?
Ovdje moramo definirati što znači smrt softverskog proizvoda. S jedne strane, uspješno se koriste (uostalom, za to su i stvoreni), što znači da žive. S druge strane, ne mogu govoriti za JFS (ne znam puno), ali ReiserFS (v3) se jako teško prilagođava novim trendovima (provjereno u praksi). To znači da u budućnosti programeri neće obraćati pažnju na njih, već na one koji se lakše prilagođavaju. S ove strane ispada da je, nažalost, mrtav u arhitektonskom smislu. Ne bih uopće manipulirao pojmom “moralno zastarjelo”. Dobro se odnosi, na primjer, na ormar, ali ne i na softverske proizvode. Postoji koncept inferiornosti i superiornosti u nečemu. Apsolutno mogu reći da je ReserFS v3 sada inferioran u odnosu na Reiser4 u svemu, ali je u nekim vrstama opterećenja bolji od svih ostalih uzvodnih FS-ova.
Znate li za razvoj FS Tux3 i HAMMER/HAMMER2 (FS za DragonFly BSD)?
Da, znamo. U Tux3 me svojedobno zanimala tehnologija njihovih snapshotova (tzv. “version pointers”), ali u Reiseru4 ćemo najvjerojatnije ići drugim putem. Dugo sam razmišljao o podršci brzim snimkama i još nisam odlučio kako ih implementirati za jednostavne Reiser4 volumene. Činjenica je da novonastala tehnika "lijenog" referentnog brojača koju je predložio Ohad Rodeh radi samo za B-stabla. Nemamo ih. Za one strukture podataka koje se koriste u Reiesr4, “lijeni” brojači nisu definirani – za njihovo uvođenje potrebno je riješiti određene algoritamske probleme, kojih se još nitko nije uhvatio u koštac.
Prema HAMMER-u: Pročitao sam članak kreatora. Ne zanima me. Opet, B-stabla. Ova struktura podataka je beznadno zastarjela. Napustili smo ga u prošlom stoljeću.
Kako procjenjujete rastuću potražnju za FS-ovima mrežnih klastera kao što su CephFS/GlusterFS/itd? Znači li ova potražnja pomak u prioritetima programera prema mrežnim FS-ovima i nedovoljnu pozornost lokalnim FS-ovima?
Da, takva promjena prioriteta se dogodila. Razvoj lokalnih datotečnih sustava je stagnirao. Nažalost, učiniti nešto značajno za lokalne količine sada je prilično teško i ne može svatko to učiniti. Nitko ne želi ulagati u njihov razvoj. To je otprilike isto kao da tražite od komercijalne organizacije da izdvoji novac za matematička istraživanja - bez imalo entuzijazma će vas pitati kako možete zaraditi na novom teoremu. Sada je lokalni FS nešto što se magično pojavljuje "izvan kutije" i "treba uvijek raditi", a ako ne radi, izaziva neadresirano gunđanje poput: "Da, što oni misle!"
Otuda i nedostatak pozornosti prema lokalnim FS, iako na tom području ima još puno posla. I da, svi su se okrenuli distribuiranoj pohrani, koja je izgrađena na temelju već postojećih lokalnih datotečnih sustava. Sada je vrlo moderno. Sintagma Big Data kod mnogih izaziva nalet adrenalina, asocirajući na konferencije, radionice, velike plaće i sl.
Koliko je u načelu razumno implementirati mrežni datotečni sustav u kernel prostor umjesto u korisnički prostor?
Vrlo razuman pristup koji još nigdje nije implementiran. Općenito, pitanje u kojem prostoru treba implementirati mrežni datotečni sustav je "mač s dvije oštrice". Pa, pogledajmo primjer. Klijent je zabilježio podatke na udaljenom računalu. One su pale u njezinu predmemoriju stranica u obliku prljavih stranica. Ovo je posao za "thin gateway" mrežni datotečni sustav u prostoru jezgre. Tada će vas operativni sustav prije ili kasnije tražiti da te stranice zapišete na disk kako biste ih oslobodili. Tada na scenu stupa mrežni FS modul za IO-prosljeđivanje (slanje). Određuje kojem poslužiteljskom stroju (poslužiteljskom čvoru) će te stranice ići.
Zatim mrežni stog preuzima (i, kao što znamo, implementiran je u prostor jezgre). Zatim čvor poslužitelja prima taj paket s podacima ili metapodacima i daje upute pozadinskom modulu za pohranu (tj. lokalnom FS-u koji radi u prostoru jezgre) da zabilježi sve te stvari. Dakle, sveli smo pitanje na to gdje bi trebali raditi moduli "slanje" i "primanje". Ako se bilo koji od tih modula izvodi u korisničkom prostoru, to će neizbježno dovesti do prebacivanja konteksta (zbog potrebe korištenja usluga jezgre). Broj takvih prekidača ovisi o detaljima izvedbe.
Ako postoji mnogo takvih prekidača, smanjit će se propusnost pohrane (I/O performanse). Ako se vaša pozadinska pohrana sastoji od sporih diskova, tada nećete primijetiti značajan pad. Ali ako imate brze diskove (SSD, NVRAM, itd.), tada prebacivanje konteksta već postaje "usko grlo" i, uštedom na prebacivanju konteksta, performanse se mogu značajno povećati. Standardni način uštede novca je premještanje modula u prostor jezgre. Na primjer, otkrili smo da premještanje 9p poslužitelja s QEMU na kernel na glavnom računalu dovodi do trostrukog povećanja izvedbe VirtFS-a.
Ovo, naravno, nije mrežni FS, ali u potpunosti odražava bit stvari. Loša strana ove optimizacije su problemi s prenosivošću. Za neke, ovo posljednje može biti kritično. Na primjer, GlusterFS uopće nema modula u kernelu. Zahvaljujući tome, sada radi na mnogim platformama, uključujući NetBSD.
Koje bi koncepte lokalni FS-ovi mogli posuditi od mrežnih i obrnuto?
Danas mrežni FS-ovi u pravilu imaju dodatke preko lokalnih FS-ova, pa mi nije sasvim jasno kako možete posuditi nešto od potonjih. Pa, doista, uzmimo u obzir tvrtku od 4 zaposlena, u kojoj svatko radi svoje: jedan distribuira, drugi šalje, treći prima, četvrti skladišti. I pitanje, što tvrtka može posuditi od svog zaposlenika koji to skladišti, zvuči nekako netočno (već ima ono što je mogla posuditi od njega odavno).
Ali lokalni FS-ovi imaju puno toga za naučiti od mrežnih. Prvo, od njih biste trebali naučiti kako agregirati logičke volumene na visokoj razini. Sada tzv "Napredni" lokalni datotečni sustavi agregiraju logičke volumene isključivo koristeći tehnologiju "virtualnog uređaja" posuđenu od LVM-a (to isto zarazno kršenje slojeva koje je prvi put implementirano u ZFS-u). Drugim riječima, prevođenje virtualnih adresa (blokovskih brojeva) u stvarne i natrag događa se na niskoj razini (tj. nakon što je datotečni sustav izdao I/O zahtjev).
Imajte na umu da dodavanje i uklanjanje uređaja na logičke volumene (ne zrcala) raspoređene na blokovnom sloju dovodi do problema o kojima dobavljači takvih "značajki" skromno šute. Govorim o fragmentaciji na stvarnim uređajima, koja može doseći monstruozne vrijednosti, dok je na virtualnom uređaju sve u redu. No, malo je ljudi zainteresirano za virtualne uređaje: sve zanima što se događa na vašim stvarnim uređajima. Ali FS nalik ZFS-u (kao i bilo koji FS u kombinaciji s LVM-om) radi samo s virtualnim diskovnim uređajima (dodijeli virtualne adrese diskova između slobodnih, defragmentiraj te virtualne uređaje itd.). I nemaju pojma što se događa na stvarnim uređajima!
Sada zamislite da imate nultu fragmentaciju na virtualnom uređaju (to jest, imate samo jedan divovski ekstent koji tamo živi), dodajete disk svom logičkom volumenu, a zatim uklonite drugi nasumični disk iz svog logičkog volumena i zatim ponovno uravnotežite. I toliko puta. Nije teško zamisliti da ćete na virtualnom uređaju i dalje živjeti u istoj mjeri, ali na stvarnim uređajima nećete vidjeti ništa dobro.
Najgore je što niste u stanju ni ispraviti ovu situaciju! Jedino što ovdje možete učiniti je zatražiti od datotečnog sustava da defragmentira virtualni uređaj. Ali ona će vam reći da je tamo sve super - postoji samo jedan opseg, fragmentacija je nula, i ne može biti bolje! Dakle, logički volumeni raspoređeni na razini bloka nisu namijenjeni opetovanom dodavanju/uklanjanju uređaja. U dobrom smislu, trebate samo jednom sastaviti logički volumen na razini bloka, dati ga datotečnom sustavu i zatim s njim ništa više ne raditi.
Osim toga, kombinacija neovisnih FS+LVM podsustava ne dopušta uzimanje u obzir različite prirode pogona iz kojih se agregiraju logički volumeni. Doista, pretpostavimo da ste sastavili logički volumen od HDD-a i solid-state uređaja. Ali tada će prvi zahtijevati defragmentaciju, a drugi neće. Za potonje trebate izdati zahtjeve za odbacivanje, ali za prvo ne, itd. Međutim, u ovoj kombinaciji prilično je teško pokazati takvu selektivnost.
Imajte na umu da nakon stvaranja vlastitog LVM-a na datotečnom sustavu situacija ne postaje puno bolja. Štoviše, čineći ovo zapravo stajete na kraj izgledima da ga ikada poboljšate u budućnosti. Ovo je jako loše. Različite vrste pogona mogu živjeti na istom stroju. A ako ih datotečni sustav ne razlikuje, tko će onda?
Drugi problem leži u čekanju tzv. Datotečni sustavi "Write-Anywhere" (ovo također uključuje Reiser4, ako ste naveli odgovarajući transakcijski model tijekom montiranja). Takvi datotečni sustavi moraju osigurati alate za defragmentaciju koji su bez presedana u svojoj moći. A upravitelj glasnoće niske razine ovdje ne pomaže, već samo smeta. Činjenica je da će s takvim upraviteljem vaš FS pohraniti kartu slobodnih blokova samo jednog uređaja - virtualnog. U skladu s tim, možete samo defragmentirati virtualni uređaj. To znači da će vaš defragmentator dugo, dugo raditi na ogromnom prostoru virtualnih adresa.
A ako imate mnogo korisnika koji nasumično prepisuju, tada će koristan učinak takvog defragmentatora biti sveden na nulu. Vaš sustav će neizbježno početi usporavati, a vi ćete samo morati sklopiti ruke pred razočaravajućom dijagnozom "pokvaren dizajn". Nekoliko programa za defragmentaciju koji rade na istom adresnom prostoru samo će ometati jedni druge. Potpuno je druga stvar ako održavate vlastitu mapu slobodnih blokova za svaki pravi uređaj. Ovo će učinkovito paralelizirati proces defragmentacije.
Ali to se može učiniti samo ako imate upravitelj logičkog volumena na visokoj razini. Lokalni datotečni sustavi s takvim upraviteljima prije nisu postojali (barem ja ne znam za njih). Takve upravitelje imali su samo mrežni datotečni sustavi (na primjer GlusterFS). Drugi vrlo važan primjer je uslužni program za provjeru integriteta volumena (fsck). Ako pohranite vlastitu neovisnu mapu slobodnih blokova za svaki podvolumen, tada se postupak za provjeru logičkog volumena može učinkovito paralelizirati. Drugim riječima, logični volumeni s upraviteljima na visokoj razini bolje se skaliraju.
Osim toga, s upraviteljima volumena niske razine nećete moći organizirati potpune snimke. S LVM i ZFS sličnim datotečnim sustavima možete napraviti samo lokalne snimke, ali ne i globalne snimke. Lokalne snimke omogućuju trenutno vraćanje samo uobičajenih operacija datoteka. I nitko tamo neće vratiti operacije s logičkim volumenima (dodavanje/uklanjanje uređaja). Pogledajmo ovo na primjeru. U nekom trenutku, kada imate logički volumen od dva uređaja A i B koji sadrži 100 datoteka, snimite snimku sustava S i zatim stvorite novih stotinu datoteka.
Nakon toga svom volumenu dodajete uređaj C i konačno vraćate sustav na snimku S. Pitanje: Koliko datoteka i uređaja sadrži vaš logički volumen nakon vraćanja na S? Bit će 100 datoteka, kao što možda pretpostavljate, ali bit će 3 uređaja - to su isti uređaji A, B i C, iako su u trenutku stvaranja snimke u sustavu bila samo dva uređaja (A i B ). Operacija dodavanja uređaja C nije se vratila, a ako sada uklonite uređaj C s računala, to će oštetiti vaše podatke, tako da ćete prije brisanja prvo morati izvesti skupu operaciju uklanjanja uređaja iz logičkog volumena rebalansa, što će raspršiti sve podatke s uređaja C na uređaje A i B. Ali ako vaš FS podržava globalne snimke, takvo ponovno balansiranje ne bi bilo potrebno, a nakon trenutnog vraćanja na S, mogli biste sigurno ukloniti uređaj C s računala.
Dakle, globalne snimke su dobre jer vam omogućuju da izbjegnete skupo uklanjanje (dodavanje) uređaja s logičkog volumena (na logički volumen) s velikom količinom podataka (naravno, ako se sjetite "snimiti" svoj sustav u pravo vrijeme). Dopustite mi da vas podsjetim da su stvaranje snimki i vraćanje datotečnog sustava na njih trenutačne operacije. Može se postaviti pitanje: kako je uopće moguće trenutačno vratiti operaciju na logičkom volumenu za koju su vam bila potrebna tri dana? Ali moguće je! Pod uvjetom da je vaš datotečni sustav ispravno dizajniran. Na ideju o takvim “3D snimkama” došao sam prije tri godine, a prošle sam godine patentirao ovu tehniku.
Sljedeća stvar koju bi lokalni FS-ovi trebali naučiti od mrežnih je pohranjivanje metapodataka na zasebne uređaje na isti način na koji ih mrežni FS-ovi pohranjuju na odvojene strojeve (tzv. metadata servere). Postoje aplikacije koje prvenstveno rade s metapodacima, a te se aplikacije mogu znatno ubrzati postavljanjem metapodataka na skupe uređaje za pohranu visokih performansi. S kombinacijom FS+LVM nećete moći pokazati takvu selektivnost: LVM ne zna što se nalazi u bloku koji ste mu proslijedili (podaci tamo ili metapodaci).
Nećete imati mnogo koristi od implementacije vlastitog LVM-a niske razine u FS u usporedbi s kombinacijom FS+LVM, ali ono što možete učiniti vrlo dobro jest zatrpati FS tako da kasnije postane nemoguće raditi s njegovim kodom. ZFS i Btrfs, koji su požurili s virtualnim uređajima, jasni su primjeri kako kršenje slojevitosti ubija sustav u arhitektonskom smislu. Dakle, zašto sam ja sve ovo? Štoviše, nema potrebe instalirati vlastiti LVM niske razine u datotečni sustav. Umjesto toga, trebate agregirati uređaje u logičke volumene na visokoj razini, kao što neki mrežni datotečni sustavi rade s različitim strojevima (čvorovima za pohranu). Istina, oni to rade odvratno zbog upotrebe loših algoritama.
Primjeri apsolutno strašnih algoritama su DHT prevoditelj u GlusterFS datotečnom sustavu i takozvana CRUSH mapa u Ceph datotečnom sustavu. Nijedan od algoritama koje sam vidio nije me zadovoljio u smislu jednostavnosti i dobre skalabilnosti. Pa sam se morao sjetiti algebre i sve sam izmisliti. 2015. godine, eksperimentirajući s bundleovima preko hash funkcija, smislio sam i patentirao nešto što mi odgovara. Sada mogu reći da je pokušaj da se sve ovo provede u praksi bio uspješan. Ne vidim nikakve probleme sa skalabilnošću u novom pristupu.
Da, svaki podvolumen će zahtijevati zasebnu strukturu kao što je superblok u memoriji. Je li ovo jako strašno? Općenito, ne znam tko će "zakuhati ocean" i stvoriti logičke volumene od stotina tisuća ili više uređaja na jednom lokalnom stroju. Ako mi netko to može objasniti, bit ću mu jako zahvalan. U međuvremenu, za mene je ovo marketinško sranje.
Kako su promjene u podsustavu kernel blok uređaja (na primjer, pojava blk-mq) utjecale na zahtjeve za implementaciju FS-a?
Nisu imale nikakvog utjecaja. Ne znam što bi se dogodilo na blok sloju da bi bilo potrebno dizajnirati novi FS. Interakcija sučelja ovih podsustava je vrlo loša. Sa strane drajvera, na FS bi trebala utjecati samo pojava novih vrsta pogona, kojima će se prvo prilagoditi blok sloj, a zatim FS (za reiser4 to će značiti pojavu novih dodataka).
Znači li pojava novih vrsta medija (na primjer, SMR ili sveprisutnost SSD-ova) fundamentalno nove izazove za dizajn datotečnog sustava?
Da. I to su normalni poticaji za razvoj FS. Izazovi mogu biti različiti i potpuno neočekivani. Na primjer, čuo sam za pogone gdje brzina I/O operacije uvelike ovisi o veličini dijela podataka i njegovom pomaku. U Linuxu, gdje veličina FS bloka ne može premašiti veličinu stranice, takav pogon prema zadanim postavkama neće pokazati svoje pune mogućnosti. Međutim, ako je vaš datotečni sustav pravilno dizajniran, tada postoji šansa da iz njega izvučete mnogo više.
Koliko ljudi osim vas trenutno radi s kodom Reiser4?
Manje nego što bih želio, ali ni ja ne osjećam akutni nedostatak resursa. Više sam nego zadovoljan tempom razvoja Reisera4. Neću "tjerati konje" - ovo nije pravo područje. Evo, "ako voziš tiše, nastavit ćeš!" Moderni datotečni sustav je najsloženiji podsustav jezgre, čije pogrešne dizajnerske odluke mogu poništiti naredne godine ljudskog rada.
Nudeći volonterima da nešto provedu, uvijek jamčim da će napori sigurno dovesti do ispravnog rezultata, koji može biti tražen za ozbiljne potrebe. Kao što razumijete, ne može biti mnogo takvih jamstava odjednom. U isto vrijeme, ne mogu podnijeti "figure" koje besramno promoviraju "značajke" očito neupotrebljivog softvera, obmanjujući stotine korisnika i programera, au isto vrijeme sjede i smješkaju se na vrhovima kernela.
Je li neka tvrtka izrazila volju podržati razvoj Reisera4?
Da, bilo je takvih prijedloga, uklj. i od glavnog dobavljača. Ali za ovo sam se morao preseliti u drugu zemlju. Nažalost, nemam više 30 godina, ne mogu se otrgnuti i otići na prvi zvižduk.
Koje značajke trenutno nedostaju Reiseru4?
Ne postoji funkcija "promjene veličine" za jednostavne volumene, slična onoj u ReiserFS(v3). Osim toga, operacije datoteka s DIRECT_IO zastavom ne bi škodile. Sljedeće, želio bih imati mogućnost razdvajanja svezaka u "semantičke podvolumene", koji nemaju fiksnu veličinu i koji se mogu montirati kao neovisni volumeni. Ovi problemi su dobri za početnike koji se žele okušati u "pravoj stvari".
I na kraju, želio bih imati mrežne logičke volumene s jednostavnom implementacijom i administracijom (moderni algoritmi to već omogućuju). Ali ono što Reiser4 sigurno nikada neće imati je RAID-Z, scrubs, predmemorije slobodnog prostora, 128-bitne varijable i druge marketinške gluposti koje su nastale u pozadini nedostatka ideja među programerima nekih datotečnih sustava.
Može li se sve što bi moglo biti potrebno implementirati pomoću dodataka?
Ako govorimo samo o sučeljima i dodacima (modulima) koji ih implementiraju, onda ne sve. Ali ako također uvedete odnose na tim sučeljima, tada ćete, između ostalog, imati koncepte viših polimorfizama, s kojima se već možete snaći. Zamislite da ste hipotetski zamrznuli objektno orijentirani runtime sustav, promijenili vrijednost pokazivača instrukcija da pokazuje na drugi dodatak koji implementira isto X sučelje, a zatim odmrznuli sustav tako da se nastavlja izvršavati.
Ako krajnji korisnik ne primijeti takvu "zamjenu", tada kažemo da sustav ima polimorfizam nultog reda u X sučelju (ili je sustav heterogen u X sučelju, što je isto). Ako sada ne samo da imate skup sučelja, već imate i odnose na njima (graf sučelja), tada možete uvesti polimorfizme viših redova, koji će karakterizirati heterogenost sustava već u "susjedstvu" bilo kojeg sučelja. Takvu sam klasifikaciju davno uveo, ali do toga, nažalost, nikada nije došlo.
Dakle, uz pomoć dodataka i takvih viših polimorfizama, možete opisati bilo koju poznatu značajku, kao i "predvidjeti" one koje nikada nisu niti spomenute. Nisam to uspio striktno dokazati, ali također još ne znam za protuprimjer. Općenito, ovo me pitanje podsjetilo na "Erlangenski program" Felixa Kleina. Svojedobno je pokušao cijelu geometriju prikazati kao granu algebre (točnije teoriju grupa).
Sada na glavno pitanje - kako stoje stvari s promocijom Reisera4 u glavnu jezgru? Je li bilo publikacija o arhitekturi ovog datotečnog sustava o kojem ste govorili u prošlom intervjuu? Koliko je ovo pitanje relevantno s vašeg gledišta?
Uglavnom, već tri godine tražimo uključenje u glavnu podružnicu. Posljednji Reiserov komentar u javnoj temi gdje je upućen zahtjev za povlačenjem ostao je bez odgovora. Dakle, sva daljnja pitanja nisu za nas. Ja osobno ne razumijem zašto se moramo "spojiti" u određeni operativni sustav. Na Linuxu se svjetlo nije skupljalo poput klina. Dakle, postoji zasebno spremište u kojem će biti nekoliko priključaka za različite operativne sustave. Kome treba može klonirati pripadajući port i raditi s njim što god hoće (unutar licence, naravno). Pa ako nekome ne treba, onda to nije moj problem. U ovom trenutku, predlažem da se pitanje "unaprijeđenja u glavnu jezgru Linuxa" razmotri kao riješeno.
Publikacije o FS arhitekturi su relevantne, ali do sada sam našao vremena samo za svoje nove rezultate, koje smatram većim prioritetom. Druga stvar je da sam ja matematičar, au matematici je svaka publikacija sažetak teorema i njihovih dokaza. Objavljivanje bilo čega tamo bez dokaza je znak lošeg ukusa. Ako temeljito dokažem ili opovrgnem bilo koju tvrdnju o arhitekturi FS-a, onda će rezultat biti takve hrpe da će biti prilično teško proći. Kome to treba? Vjerojatno je to razlog zašto sve ostaje u starom obliku - izvorni kod i komentari na njega.
Što je novo u Reiseru4 u posljednjih nekoliko godina?
Dugo očekivana stabilnost napokon se materijalizirala. Jedna od posljednjih koja se pojavila bila je greška koja je dovela do direktorija koji se ne mogu izbrisati. Poteškoća je bila u tome što se pojavljivao samo u pozadini kolizija hash imena i s određenom lokacijom zapisa imenika u čvoru stabla. Međutim, još uvijek ne mogu preporučiti Reiser4 za proizvodnju: za ovo morate obaviti nešto uz aktivnu interakciju s administratorima proizvodnog sustava.
Napokon smo uspjeli realizirati našu dugogodišnju ideju - različite modele transakcija. Prethodno je Reiser4 pokretao samo jedan Macdonald-Reiserov model s tvrdim kodom. To je stvorilo probleme s dizajnom. Konkretno, snimke nisu moguće u takvom transakcijskom modelu - one će biti oštećene atomskom komponentom pod nazivom "OVERWRITE SET". Reiser4 trenutno podržava tri modela transakcija. U jednom od njih (Write-Anywhere), atomska komponenta OVERWRITE SET uključuje samo sistemske stranice (slike bitmapa diska itd.), koje se ne mogu “fotografirati” (problem kokoši i jajeta).
Tako se slike sada mogu realizirati na najbolji mogući način. U drugom transakcijskom modelu, sve modificirane stranice idu samo u OVERWRITE SET (to jest, to je u biti čisto vođenje dnevnika). Ovaj model je za one koji su se žalili na brzu fragmentaciju Reiser4 particija. Sada se u ovom modelu vaša particija neće fragmentirati ništa brže nego s ReiserFS (v3). Sva tri postojeća modela, uz određene rezerve, jamče atomičnost operacija, ali mogu biti korisni i modeli s gubitkom atomičnosti i očuvanjem samo cjelovitosti presjeka. Takvi modeli mogu biti korisni za sve vrste aplikacija (baze podataka i sl.), koje su već preuzele neke od ovih funkcija. Vrlo je lako dodati ove modele u Reiser4, ali ja to nisam napravio, jer me nitko nije pitao, a meni osobno ne treba.
Pojavile su se kontrolne sume metapodataka i nedavno sam ih dopunio “ekonomičnim” ogledalima” (još uvijek nestabilan materijal). Ako kontrolni zbroj bilo kojeg bloka ne uspije, Reiser4 odmah čita odgovarajući blok s replike uređaja. Imajte na umu da ZFS i Btrfs to ne mogu učiniti: dizajn to ne dopušta. Tamo morate pokrenuti poseban proces skeniranja pozadine koji se zove "scrub" i pričekati da dođe do problematičnog bloka. Programeri takve događaje figurativno nazivaju "štakama".
I konačno, pojavili su se heterogeni logički volumeni koji nude sve ono što ZFS, Btrfs, block layer, kao ni FS+LVM kombinacije u principu ne mogu pružiti - paralelno skaliranje, O(1) disk address allocator, transparentnu migraciju podataka između podvolumena. Potonji također ima korisničko sučelje. Sada možete jednostavno premjestiti najtoplije podatke na pogon s najboljim performansama na svom volumenu.
Osim toga, moguće je hitno isprati sve prljave stranice na takav pogon, čime se znatno ubrzavaju aplikacije koje često pozivaju fsync(2). Napominjem da funkcionalnost blok sloja, nazvana bcache, uopće ne pruža takvu slobodu djelovanja. Novi logički volumeni temelje se na mojim algoritmima (postoje odgovarajući patenti). Softver je već prilično stabilan, sasvim je moguće isprobati ga, izmjeriti performanse itd. Jedina neugodnost je što za sada trebate ručno ažurirati konfiguraciju volumena i negdje je pohraniti.
Do sada sam uspio implementirati svoje ideje za 10 posto, no uspio sam u onome što sam smatrao najtežim - povezivanje logičkih volumena s flash procedurom koja obavlja sve odgođene radnje u reiseru4. Ovo je još uvijek u eksperimentalnoj grani "format41".
Prolazi li Reiser4 xfstestove?
Barem je meni bilo kad sam pripremao zadnje izdanje.
Je li u principu moguće napraviti Reiser4 kao mrežni (cluster) FS pomoću dodataka?
Moguće je, pa čak i potrebno! Ako stvorite mrežnu datoteku na temelju pravilno dizajniranog lokalnog datotečnog sustava, rezultat će biti vrlo impresivan! U modernim mrežnim FS-ovima nisam zadovoljan prisutnošću pozadinske razine pohrane koja se implementira pomoću bilo kojeg lokalnog FS-a. Postojanje ove razine potpuno je neopravdano. Mrežni FS mora izravno komunicirati s blok slojem, a ne tražiti od lokalnog FS-a da stvori bilo koje druge servisne datoteke!
Općenito, podjela datotečnih sustava na lokalne i mrežne je od zla. Nastao je iz nesavršenosti algoritama koji su korišteni prije trideset godina, a umjesto kojih još ništa nije predloženo. To je također razlog za pojavu mase nepotrebnih softverskih komponenti (razne usluge, itd.). Na dobar način, trebao bi postojati samo jedan FS u obliku modula jezgre i skupa korisničkih uslužnih programa instaliranih na svakom stroju - čvor klastera. Ovaj FS je i lokalni i mrežni. I ništa više!
Ako ništa ne uspije s Reiserom4 na Linuxu, želio bih ponuditi FS za FreeBSD (citat iz prethodnog intervjua: “...FreeBSD... ima akademske korijene... A to znači da s velikim stupnjem vjerojatnosti naći će zajednički jezik s programerima”) ?
Dakle, kao što smo upravo saznali, sve je već savršeno funkcioniralo s Linuxom: postoji zaseban radni Reiser4 port za njega u obliku glavne grane našeg repozitorija. Nisam zaboravio FreeBSD! Ponuda! Spreman sam blisko surađivati s onima koji dobro poznaju unutrašnjost FreeBSD-a. Usput: ono što mi se jako sviđa kod njihove zajednice je to što tamo odluke donosi ažurirano vijeće neovisnih stručnjaka, što nema nikakve veze s vladinom obmanom jedne stalne osobe.
Kako ocjenjujete zajednicu korisnika Linuxa danas? Je li postalo više "pop"?
S obzirom na prirodu mog posla, dosta mi je teško to procijeniti. Uglavnom mi korisnici dolaze s izvješćima o greškama i zahtjevima da popravim odjeljak. Korisnici kao korisnici. Neki su pametniji, neki manje. Svi su tretirani isto. Pa, ako korisnik ignorira moje upute, ispričajte me: nalog za ignoriranje bit će upisan i s moje strane.
Je li moguće predvidjeti razvoj datotečnih sustava za sljedećih pet do deset godina? Što mislite koji su glavni izazovi s kojima se programeri FS-a mogu suočiti?
Da, nije teško napraviti takvu prognozu. Već dugo nije bilo razvoja datotečnih sustava u upstreamu. Stvara se samo privid takvih. Programeri lokalnih datotečnih sustava naišli su na probleme povezane s lošim dizajnom. Ovdje treba napraviti upozorenje. Takozvano "pohranjivanje", "lizanje" i portiranje koda ne smatram razvojem i razvojem. I ne svrstavam nesporazum zvan "Btrfs" u razvoj iz razloga koje sam već objasnio.
Svaka zakrpa samo pogoršava probleme. Dobro. i uvijek postoje razne vrste "evanđelista" kojima "sve ide". Uglavnom, radi se o učenicima i studentima koji bježe s predavanja. Zamislite: njemu to ide, a profesoru ne. Kakav je ovo adrenalin! S moje točke gledišta, najveću štetu uzrokuju "obrtnici" koji su požurili s entuzijazmom "zašarafiti" prekrasne značajke Btrfs-a na sve vrste slojeva kao što su systemd, docker itd. - ovo već podsjeća na metastaze.
Pokušajmo sada napraviti prognozu za pet do deset godina. Već sam ukratko naveo što ćemo raditi u Reiseru4. Glavni izazov za lokalne FS programere od gore bit će (da, već je postao) nemogućnost obavljanja pristojnog posla za plaću. Bez ikakvih ideja na polju pohranjivanja podataka i dalje će pokušavati krpati ove nesretne VFS, XFS i ext4. Situacija s VFS-om na tom planu izgleda posebno komično, podsjećajući na bjesomučnu modernizaciju restorana u kojem kuhara nema, a niti se očekuju.
Sada VFS kod, bez ikakvih uvjeta, zaključava nekoliko memorijskih stranica u isto vrijeme i poziva temeljni FS da radi na njima. Ovo je uvedeno kako bi se poboljšala izvedba Ext4 na operacijama brisanja, ali kao što je lako razumjeti, takvo istovremeno zaključavanje potpuno je nekompatibilno s naprednim modelima transakcija. To jest, nećete moći jednostavno dodati podršku za neki pametni datotečni sustav u kernelu. Ne znam kakva je situacija u drugim područjima Linuxa, ali što se tiče datotečnih sustava, malo je vjerojatno da će bilo kakav razvoj ovdje biti kompatibilan s politikom koju provodi Torvalds u praksi (akademski projekti su izbačeni, a prevaranti koji nemam pojma što je B-stablo, izdaju se beskrajni krediti povjerenja). Stoga je krenulo polagano propadanje. Naravno, svim silama će to pokušati prikazati kao “razvoj”.
Nadalje, "čuvari" datotečnih sustava, shvativši da se ne može puno zaraditi samo od "pohrane", okušat će se u profitabilnijem poslu. To su u pravilu distribuirani datotečni sustavi i virtualizacija. Možda će moderni ZFS prebaciti negdje drugdje gdje još ne postoji. Ali on, kao i svi FS-ovi uzvodno, podsjeća na novogodišnju jelku: ako možete objesiti neke druge sitnice na vrh, onda ne možete dublje. Priznajem da je moguće izgraditi ozbiljan poslovni sustav temeljen na ZFS-u, ali budući da sada razgovaramo o budućnosti, mogu samo žalosno konstatirati da je ZFS beznadežan u tom pogledu: sa svojim virtualnim uređajima dečki su presjekli kisik za sebe i buduće generacije za daljnji razvoj. ZFS je stvar prošlosti. A ext4 i XFS nisu ni prekjučer.
Vrijedno je posebno spomenuti senzacionalni koncept "Linux datotečni sustav sljedeće generacije". Ovo je potpuno politički i marketinški projekt stvoren za priliku, da tako kažemo, da se iza određenih likova “pričvrsti budućnost datotečnih sustava” u Linuxu. Činjenica je da je Linux prije bio “samo za zabavu”. Ali sada je to prvenstveno stroj za stvaranje novca. Napravljene su na svemu mogućem. Na primjer, vrlo je teško napraviti dobar programski proizvod, ali pametni “programeri” su odavno shvatili da se uopće ne treba naprezati: možete uspješno prodavati nepostojeći softver koji je najavljivan i promoviran na svim mogućim javnim mjestima. događaji - glavna stvar je da slajdovi prezentacije trebaju sadržavati više "značajki".
Datotečni sustavi savršeni su za to, jer se o rezultatu možete sigurno cjenkati deset godina. Pa, ako se netko kasnije žali na nedostatak ovog rezultata, onda jednostavno ne razumije ništa o datotečnim sustavima! Ovo podsjeća na financijsku piramidu: na vrhu su avanturisti koji su započeli ovu zbrku i oni rijetki koji su imali “sreće”: “izvukli su dividende”, tj. primali novac za razvoj, dobili dobro plaćeni posao menadžera, “pojavljivali” se na konferencijama itd.
Slijede oni koji “nemaju sreće”: oni će brojati gubitke, nositi se s posljedicama postavljanja neupotrebljivog softverskog proizvoda u proizvodnju, itd. Ima ih puno više. Pa, u osnovi piramide postoji ogromna masa programera koji "pile" beskoristan kod. Oni su najveći gubitnici, jer izgubljeno vrijeme se ne može vratiti. Takve su piramide iznimno korisne Torvaldsu i njegovim suradnicima. I što više tih piramida, to bolje za njih. Da bi se hranile takve piramide, u jezgru se može unijeti bilo što. Naravno, u javnosti se govori suprotno. Ali ja ne sudim po riječima nego po djelima.
Dakle, "budućnost datotečnih sustava u Linuxu" je još jedan visoko promoviran, ali teško upotrebljiv softver. Nakon Btrfs-a, s velikom vjerojatnošću, mjesto takve “budućnosti” će zauzeti Bcachefs, što je još jedan pokušaj križanja Linux block sloja s datotečnim sustavom (loš primjer je zarazan). I ono što je tipično: postoje isti problemi kao u Btrfs. Dugo sam sumnjao u to, a onda nekako nisam mogao odoljeti i pogledao u šifru - istina je!
Autori Bcachefs i Btrfs, kada su stvarali svoje FS, aktivno su koristili tuđe izvore, malo ih razumijevajući. Situacija jako podsjeća na dječju igricu “pokvaren telefon”. I mogu otprilike zamisliti kako će ovaj kod biti uključen u kernel. Zapravo, nitko neće vidjeti “grablje” (kasnije će svi stati na njih). Nakon brojnih zamjerki oko stila koda, optužbi za nepostojeća kršenja itd., doći će do zaključka o “lojalnosti” autora, koliko dobro “interaguje” s drugim programerima i koliko uspješno sve to može zatim prodati korporacijama.
Krajnji rezultat nikoga neće zanimati. Prije dvadesetak godina možda bi me i zanimalo, ali sada se pitanja postavljaju drugačije: hoće li se to uspjeti pospješiti tako da se u sljedećih deset godina zaposle određeni ljudi. I, nažalost, nije uobičajeno pitati se o krajnjem rezultatu.
Općenito, izričito bih savjetovao da ne počnete ponovno izmišljati svoj datotečni sustav od nule. Jer ni značajna financijska ulaganja neće biti dovoljna da se za deset godina dobije nešto konkurentno. Naravno, govorim o ozbiljnim projektima, a ne o onima koji se namjeravaju “ugurati” u kernel. Dakle, učinkovitiji način da se izrazite jest pridružiti se stvarnom razvoju, poput nas. To, naravno, nije lako učiniti - ali to je slučaj sa svakim projektom na visokoj razini.
Prvo ćete morati samostalno prevladati problem koji ću ponuditi. Nakon čega ću, uvjeren u ozbiljnost vaših namjera, početi pomagati. Tradicionalno, koristimo samo vlastiti razvoj. Izuzetak su algoritmi kompresije i neke hash funkcije. Ne šaljemo programere da putuju na konferencije, a onda ne sjedimo i kombiniramo tuđe ideje ("možda što bude"), kao što je to uobičajeno u većini startupa.
Sve algoritme razvijamo sami. Trenutno me zanimaju algebarski i kombinatorni aspekti znanosti o pohrani podataka. Konkretno, konačna polja, asimptotika, dokaz nejednakosti. Ima posla i za obične programere, ali moram vas odmah upozoriti: svi prijedlozi da “pogledate drugi FS i učinite isto” se ignoriraju. Zakrpe usmjerene na bližu integraciju s Linuxom putem VFS-a također će ići tamo.
Dakle, nemamo grablje, ali imamo razumijevanja gdje se trebamo kretati i imamo uvjerenja da je taj smjer pravi. Ovo razumijevanje nije došlo u obliku mane s neba. Dopustite mi da vas podsjetim da imamo 29 godina iskustva u razvoju iza nas, dva datotečna sustava napisana od nule. I isti broj uslužnih programa za oporavak podataka. A ovo je puno!
Izvor: opennet.ru