Avaldatud on teine intervjuu failisüsteemi Reiser4 arendaja Eduard Šiškiniga.
Alustuseks tuletage lugejatele meelde, kus ja kelle heaks töötate.
Töötan Saksamaa uurimiskeskuses Huawei Technologies peaarhitektina. Virtualiseerimisosakonnas tegelen erinevate andmete salvestamise aspektidega. Minu tegevused ei ole seotud konkreetse operatsioonisüsteemiga.
Kas olete praegu pühendunud põhikerneli harule?
Väga harva ja ainult siis, kui mu tööandja seda nõuab. Viimati saatsin umbes kolm aastat tagasi paigad, et suurendada 9p-protokolli (selle ettevõtte teine nimi on VirtFS) hostides jagatud salvestusruumi läbilaskevõimet. Siinkohal tuleb ära märkida üks oluline märkus: kuigi olen Linuxiga juba pikemat aega töötanud, pole ma selle austaja olnud ehk “hingan ühtlaselt”, nagu ka kõige muuga. Eelkõige, kui märkan viga, võin sellele kõige rohkem ühe korra tähelepanu juhtida. Ja et saaksite siis kedagi jälgida ja veenda - seda ei juhtu.
Mäletan, et viimati, kümme aastat tagasi, olite kerneli arendusstiili suhtes üsna kriitiline. Kas teie (või võib-olla ettevõtte) vaatenurgast on midagi muutunud, kas kogukond on muutunud vastutulelikumaks või mitte? Kui ei, siis kes on teie arvates süüdi?
Ma ei näinud kunagi mingeid muutusi paremuse poole. Kogukonna põhiprobleemiks on teaduse asendamine poliittehnoloogiaga, isiklikud suhted, enamuse arvamus, populism, “sisehäälte” nõuanded, mädad kompromissid, kõik muu kui teadus. Arvutiteadus, mida iganes võib öelda, on ennekõike täppisteadus. Ja kui keegi hakkab "Linux way" lipu all või mõne muu lipu all kuulutama oma väärtust 2x2 jaoks, mis erineb 4-st, siis tõenäoliselt ei too see midagi muud kui kahju.
Kõik hädad on eelkõige tingitud otsustajate saamatusest ja harimatusest. Kui juht on ebapädev, ei suuda ta teha objektiivset, adekvaatset otsust. Kui ta on ka ebakultuurne, ei suuda ta leida pädevat spetsialisti, kes talle õiget nõu annaks. Suure tõenäosusega langeb valik petturile, kes ütleb "näiliselt õiged asjad". Ebakompetentsete üksikute juhtide ümber tekib alati korrumpeerunud keskkond. Pealegi ei tunne ajalugu selles osas erandeid ja kogukond on selle selgeim kinnitus.
Kuidas hindate Btrfsi arendamise edusamme? Kas see FS sai lastehaigustest lahti? Kuidas te seda enda jaoks positsioneerite – FS-ina "koduks" või ka ettevõtte kasutamiseks?
Ma ei saanud sellest lahti. Kõik, mida mainisin 11 aastat tagasi, on aktuaalne ka tänapäeval. Üks Btrfsi probleeme, mis muudab selle tõsiste vajaduste jaoks sobimatuks, on vaba ruumi probleem. Ma ei räägi isegi sellest, et kasutajal palutakse poodi uue ketta järele joosta olukordades, kus mõni muu FS näitaks partitsioonil palju vaba ruumi. Ka see, et vaba ruumi puudumise tõttu ei saa loogilise helitugevusega toimingut lõpule viia, pole kõige hullem. Halvim on see, et privilegeerimata kasutaja saab peaaegu alati kettakvootidest mööda minna ja üsna lühikese aja jooksul kõigilt vaba ruumi ilma jätta.
See näeb välja selline (testitud Linuxi kerneli 5.12 jaoks). Värskelt installitud süsteemis käivitatakse skript, mis loob tsüklina teatud nimedega failid kodukataloogi, kirjutab neile andmed teatud nihkega ja seejärel kustutab need failid. Pärast minutit selle skripti käivitamist ei juhtu midagi ebatavalist. Viie minuti pärast suureneb vaheseina hõivatud ruumi osa veidi. Kahe kuni kolme tunni pärast jõuab see 50% -ni (algväärtusega 15%). Ja pärast viie-kuuetunnist tööd jookseb skript kokku veaga "sektsioonil pole vaba ruumi". Pärast seda ei saa te enam oma partitsiooni kirjutada isegi 4K-faili.
Tekib huvitav olukord: te ei kirjutanud partitsioonile midagi ja kogu vaba ruum (umbes 85%) kadus kuhugi. Sellise rünnaku all oleva jaotise analüüs paljastab palju puusõlmi, mis sisaldavad vaid ühte elementi (võtmega varustatud objekt), mille suurus on mitu baiti. See tähendab, et sisu, mis varem hõivas 15% kettaruumist, osutus kogu partitsioonile ühtlaselt "määrituks", nii et uut faili pole kuhugi kirjutada, kuna selle võti on suurem kui kõik olemasolevad ja vaba partitsiooni plokid on otsa saanud.
Veelgi enam, see kõik toimub juba Btrfsi põhikonfiguratsioonis (ilma hetktõmmiste, alamköidete jne) ja pole vahet, kuidas otsustate failikehasid sellesse FS-i salvestada (puu "fragmentidena" või ulatustena). vormindamata plokkidest) - lõpptulemus on sama.
Te ei saa selliseid rünnakuid allutada teistele ülesvoolu failisüsteemidele (ükskõik, mida nad teile ütlevad). Seletasin probleemi põhjust juba ammu: see on Btrfs-i B-puu kontseptsiooni täielik moonutamine, mis võimaldab sellel spontaanselt või tahtlikult manduda. Eelkõige laguneb teie failisüsteem teatud koormuste korral iseseisvalt töötamise ajal pidevalt ilma kõrvalise abita. On selge, et kõikvõimalikud “pressivad” taustaprotsessid päästavad päeva vaid üksikutel töölaudadel.
Kollektiivsetes serverites on ründajal alati võimalik neist ette jõuda. Süsteemiadministraator ei suuda isegi kindlaks teha, kes teda täpselt kiusas. Kiireim viis selle probleemi lahendamiseks Btrfs-is on taastada tavalise B-puu struktuur, st. kettavormingu ümberkujundamine ja oluliste osade Btrfs-koodi ümberkirjutamine. See võtab 8–10 aastat, sealhulgas silumine, eeldusel, et arendajad järgisid rangelt algupäraseid artikleid asjakohaste algoritmide ja andmestruktuuride kohta ega mänginud mängu "katkine telefon", nagu Linuxis tavaks (ja julgustatakse). tee".
Siin peame lisama ka aja, mis kulub arendajatele selle kõige mõistmiseks. Siin läheb see keerulisemaks. Igatahes ei piisanud 10 aastast, et nad aru saaksid. Noh, kuni selle ajani ei saa te imele loota. See ei toimu paigaldusvalikuna „millest sina ja mina ei teadnud” ega plaastri kujul, mille ettevalmistamine on „lihtsalt äriküsimus”. Iga sellise kiirustava "paranduse" kohta esitan uue mandumise stsenaariumi. B-puud on üks mu lemmikteemasid ja pean ütlema, et need struktuurid ei talu vabadusi iseendaga!
Kuidas positsioneerida Btrfsid enda jaoks? Midagi, mida absoluutselt ei saa nimetada failisüsteemiks, rääkimata kasutamisest. Sest definitsiooni järgi on FS OS-i alamsüsteem, mis vastutab "kettaruumi" ressursi tõhusa haldamise eest, mida me Btrfs-i puhul ei näe. Kujutage ette, et tulite poodi kella ostma, et mitte tööle hiljaks jääda, ja kella asemel müüdi teile elektrigrill koos taimeriga maksimaalselt 30 minutiks. Seega on olukord Btrfsiga veelgi hullem.
Postiloendeid sirvides puutun sageli kokku väitega, et kettaruumi efektiivne haldamine pole draivide odavuse tõttu enam asjakohane. See on täielik jama. Ilma tõhusa kettaruumi haldurita muutub OS haavatavaks ja kasutamiskõlbmatuks. Sõltumata teie masina ketaste mahust.
Paluksin kommentaari Btrfs-i toe katkestamise kohta RHEL-is.
Siin pole midagi erilist kommenteerida, kõik on väga selge. Neil oli see ka "tehnoloogia eelvaade". Niisiis, ma ei läbinud seda "eelvaadet". Ärge laske sellel sildil igavesti rippuda! Kuid nad ei saa täieliku toega turule tuua defektset kaasdisaini toodet. RHEL on ettevõte, see tähendab ettekirjutatud kauba-raha suhted. Red Hat ei saa kasutajaid kiusata, nagu nad teevad Btrfsi meililistis. Kujutage vaid ette olukorda: klient, kes maksis oma raskelt teenitud raha ketta ja ka teile toe eest, tahab aru saada, kuhu tema kettaruum läks pärast seda, kui ta midagi üles ei kirjutanud. Mida sa talle sellele vastad?
Edasi. Red Hati klientide hulka kuuluvad tuntud suured pangad ja börsid. Kujutage ette, mis juhtuks, kui neile langetaks DoS-rünnakud, mis põhinevad mainitud Btrfs-i haavatavus. Kes teie arvates selle eest vastutab? Neile, kes hakkavad näpuga näitama GPL-litsentsi rea peale, kus on kirjas, et autor ei vastuta millegi eest, ütlen kohe: "peidake ära!" Red Hat vastab ja nii, et sellest ei piisa! Kuid ma tean, et Red Hatil ei ole sellist probleemi silmitsi, arvestades nende eriti tugevat kvaliteedikontrolli inseneride meeskonda, kellega mul oli võimalus omal ajal tihedat koostööd teha.
Miks mõned ettevõtted jätkavad Btrf-ide toetamist oma ettevõtte toodetes?
Pange tähele, et eesliide "ettevõte" tootenimes ei tähenda palju. Ettevõtlus on kliendiga sõlmitud lepingulistesse suhetesse sisseehitatud vastutuse mõõt. Ma tean ainult ühte GNU/Linuxil põhinevat ettevõtet – RHEL. Kõik muu on minu vaatevinklist esitatud ainult ettevõtmisena, kuid see pole üks. Ja lõpuks, kui millegi järele on nõudlus, siis on alati ka pakkumist (meie puhul on selleks mainitud “toetus”). Nõudlust on absoluutselt kõige järele, sh. ja kasutamiskõlbmatu tarkvara. Kuidas selline nõudlus tekib ja kes seda toidab, on teine teema.
Niisiis, ma ei teeks mingeid järeldusi pärast seda, kui Facebook on kuuldavasti juurutanud oma serverites Btrfsi. Lisaks soovitaksin ülaltoodud põhjustel nende serverite aadresse hoolikalt salajas hoida.
Miks on viimasel ajal XFS-koodi puhastamisega nii palju vaeva nähtud? Lõppude lõpuks on see esialgu kolmanda osapoole failisüsteem ja ext4 on olnud pikka aega stabiilne ja sellel on järjepidevus varasematest võrdselt stabiilsetest versioonidest. Millist huvi tunneb Red Hat XFS-i vastu? Kas on mõtet aktiivselt arendada kahte sarnase eesmärgiga failisüsteemi - ext4 ja XFS?
Ma ei mäleta, mis seda ajendas. On täiesti võimalik, et initsiatiiv tuli Red Hati klientidelt. Mäletan, et sedalaadi uuringud viidi läbi: mõnes ülesvoolu failisüsteemis loodi uue põlvkonna tipptasemel draividel hiiglaslik arv objekte. Tulemuste kohaselt käitus XFS paremini kui ext4. Nii hakkasid nad seda reklaamima kui kõige lootustandvamat. Igatahes ma ei otsiks siit midagi sensatsioonilist.
Minu jaoks on see nii, nagu nad oleks tiiva seebiga asendanud. Ext4 ja XFS-i pole mõtet arendada. Nii paralleelselt kui ka mis tahes neist valida. Sellest ei tule midagi head. Kuigi looduses tuleb sageli ette olukordi, kus kasvupotentsiaali on palju, aga kasvuruumi pole. Sel juhul tekivad erinevad veidralt koledad uuskasvud, millele kõik näpuga näitavad (“Oh, vaata, mida sa siin elus ei näe!”).
Kas arvate, et kihtide rikkumise probleem on lahendatud (negatiivses mõttes) koos ext4, F2FS-i krüpteerimisfunktsioonide tulekuga (rääkimata RAID-ist Btrfs-is)?
Üldjuhul on igasuguste tasandite kehtestamine ja nende mitterikkumise kohta otsuse tegemine enamasti poliitika küsimus ja ma ei võta siinkohal ette midagi kommenteerima. Kihi rikkumise objektiivsed aspektid ei paku kellelegi suurt huvi, kuid mõnda neist võime käsitleda rikkumise näitel "ülevalt", nimelt plokikihil juba olemasoleva funktsionaalsuse juurutamine FS-is. Selline "rikkumine" on õigustatud ainult harvade eranditega. Iga sellise juhtumi puhul peate esmalt tõestama kahte asja: seda, et seda on tõesti vaja ja et see ei kahjusta süsteemi ülesehitust.
Näiteks peegeldamine, mis on traditsiooniliselt olnud plokikihi tegevus, on mõttekas rakendada failisüsteemi tasemel. Erinevatel põhjustel. Näiteks "vaikiv" andmete rikumine (bitimädanik) toimub kettadraividel. See on siis, kui seade töötab korralikult, kuid plokiandmed saavad ootamatult kahjustatud kauge kvasari kiirgava kõva gamma kvanti mõjul jne. Kõige hullem on see, kui see plokk osutub FS-i süsteemiplokiks (superplokk, bitmap-plokk, salvestuspuu sõlm jne), sest see toob kindlasti kaasa kerneli paanika.
Pange tähele, et plokikihi (nn RAID 1) pakutavad peeglid ei päästa teid sellest probleemist. No tõesti: keegi peaks tõrke korral kontrollsummasid kontrollima ja koopiat lugema? Lisaks on mõttekas peegeldada mitte ainult kõike, vaid ainult metaandmeid. Mõningaid olulisi andmeid (nt kriitiliste rakenduste käivitatavad failid) saab salvestada metaandmetena. Sel juhul saavad nad samad ohutustagatised. Ülejäänud andmete kaitse on mõttekas usaldada teistele alamsüsteemidele (võib-olla isegi kasutajarakendustele) – oleme selleks kõik vajalikud tingimused pakkunud.
Sellistel "ökonoomsetel" peeglitel on õigus eksisteerida ja neid saab tõhusalt korraldada ainult failisüsteemi tasemel. Vastasel juhul on kihilisuse rikkumine alamsüsteemi risustamine dubleeritud koodiga, et saada mõningaid mikroskoopilisi eeliseid. Selle ilmekaks näiteks on RAID-5 rakendamine FS-i abil. Sellised lahendused (oma RAID / LVM failisüsteemis) tapavad viimase arhitektuurilises mõttes. Siinkohal tuleb ka märkida, et mitmesugused turunduspetturid panevad kihistamise rikkumisi "voogu". Ideede puudumisel lisatakse alamsüsteemidesse naabertasanditel juba ammu juurutatud funktsionaalsust, seda esitletakse uue ülimalt kasuliku funktsioonina ja seda aktiivselt edasi lükatakse.
Reiser4 süüdistati tasemete "altpoolt" rikkumises. Lähtudes sellest, et failisüsteem ei ole monoliitne, nagu kõik teisedki, vaid modulaarne, tehti põhjendamatu eeldus, et see teeb seda, mida kõrgemal tasemel (VFS) peaks tegema.
Kas saab rääkida ReiserFS v3.6 ja näiteks JFS-i surmast? Viimasel ajal pole neile peaaegu üldse tähelepanu pööratud. Kas need on vananenud?
Siin peame määratlema, mida tarkvaratoote surm tähendab. Ühest küljest kasutatakse neid edukalt (selleks nad ju loodi), mis tähendab, et nad elavad. Teisest küljest ei saa ma rääkida JFS-i eest (ma ei tea palju), kuid ReiserFS-i (v3) on väga raske uute trendidega kohaneda (praktikas testitud). See tähendab, et tulevikus pööravad arendajad tähelepanu mitte sellele, vaid neile, mida on lihtsam kohandada. Sellest küljest selgub, et paraku on see arhitektuurilises mõttes surnud. Ma ei manipuleeriks üldse mõistega “moraalselt vananenud”. See kehtib hästi näiteks garderoobi, kuid mitte tarkvaratoodete kohta. Milleski on alaväärsuse ja paremuse mõiste. Võin kindlalt väita, et ReserFS v3 on nüüd kõiges Reiser4-st madalam, kuid teatud tüüpi töökoormuse puhul on see parem kui kõik teised ülesvoolu FS-id.
Kas tead FS Tux3 ja HAMMER/HAMMER2 (FS for DragonFly BSD) arendamisest?
Jah, me teame. Tux3-s huvitas mind kunagi nende hetktõmmiste (nn versiooniosutajate) tehnoloogia, kuid Reiser4-s läheme suure tõenäosusega teist teed. Olen pikka aega mõelnud hetktõmmiste toetamise peale ega ole veel otsustanud, kuidas neid lihtsate Reiser4 köidete jaoks rakendada. Fakt on see, et Ohad Rodehi pakutud uus "laisk" võrdlusloendur töötab ainult B-puude puhul. Meil pole neid. Nende andmestruktuuride jaoks, mida Reiesr4-s kasutatakse, pole “laiskaid” loendureid määratletud - nende tutvustamiseks on vaja lahendada teatud algoritmilised probleemid, mida keegi pole veel võtnud.
HAMMERi sõnul: Lugesin looja artiklit. Ei ole huvitatud. Jälle B-puud. See andmestruktuur on lootusetult vananenud. Me loobusime sellest eelmisel sajandil.
Kuidas hindate kasvavat nõudlust võrguklastri FS-ide, nagu CephFS/GlusterFS/jne, järele? Kas see nõudlus tähendab arendajate prioriteetide nihkumist võrgu FS-i suunas ja ebapiisavat tähelepanu kohalikule FS-ile?
Jah, selline prioriteetide nihe on toimunud. Kohalike failisüsteemide areng on soiku jäänud. Paraku on kohalike mahtude jaoks millegi märkimisväärse tegemine praegu üsna keeruline ja kõik ei saa sellega hakkama. Keegi ei taha nende arengusse investeerida. See on umbes sama, kui paluda kommertsorganisatsioonil eraldada raha matemaatiliste uuringute jaoks – ilma entusiasmita küsivad nad teilt, kuidas saate uue teoreemiga raha teenida. Nüüd on kohalik FS midagi, mis näib võluväel "kastist välja" ja "peaks alati töötama" ja kui see ei tööta, põhjustab see adresseerimata nurinat nagu: "Jah, mida nad mõtlevad!"
Sellest ka vähene tähelepanu kohalikule FS-ile, kuigi tööd on selles vallas veel palju. Ja jah, kõik on pöördunud hajutatud salvestusruumi poole, mis on üles ehitatud juba olemasolevate kohalike failisüsteemide baasil. See on praegu väga moes. Väljend “Big Data” tekitab paljudes adrenaliinilaksu, seostades seda konverentside, töötubade, suurte palkade jms.
Kui mõistlik on põhimõtteliselt rakendada võrgufailisüsteemi kerneliruumis, mitte kasutajaruumis?
Väga mõistlik lähenemine, mida pole veel kuskil rakendatud. Üldiselt on küsimus, millises ruumis tuleks võrgufailisüsteemi rakendada, "kahe teraga mõõk". Noh, vaatame näidet. Klient salvestas andmed kaugmasinasse. Need sattusid tema lehe vahemällu määrdunud lehtedena. See on töö "õhukese lüüsi" võrgufailisüsteemi jaoks tuumaruumis. Siis palub operatsioonisüsteem varem või hiljem need lehed kettale kirjutada, et need vabastada. Seejärel tuleb mängu IO-edastus (saatmise) võrgu FS-moodul. See määrab, millisele serverimasinale (serverisõlmele) need lehed lähevad.
Seejärel võtab võimu üle võrgupinn (ja nagu me teame, realiseeritakse see tuumaruumis). Järgmisena võtab serverisõlm vastu selle andmete või metaandmetega paketi ja annab taustamälumoodulile (st kohalikule FS-ile, mis töötab kerneliruumis) käsu kogu see kraam salvestada. Seega oleme taandanud küsimuse sellele, kus peaksid "saatmise" ja "vastuvõtmise" moodulid töötama. Kui mõni neist moodulitest töötab kasutajaruumis, toob see paratamatult kaasa kontekstivahetuse (vajaduse tõttu kasutada kerneli teenuseid). Selliste lülitite arv sõltub rakenduse üksikasjadest.
Kui selliseid lüliteid on palju, siis mälu läbilaskevõime (I/O jõudlus) väheneb. Kui teie taustamälu koosneb aeglastest ketastest, ei märka te olulist langust. Kuid kui teil on kiired kettad (SSD, NVRAM jne), muutub konteksti vahetamine juba "pudelikaelaks" ja kontekstivahetuse pealt kokku hoides saab jõudlust oluliselt suurendada. Tavaline viis raha säästmiseks on viia moodulid kerneli ruumi. Näiteks leidsime, et 9p-serveri teisaldamine QEMU-st hostmasina kernelisse suurendab VirtFS-i jõudlust kolmekordselt.
See pole muidugi võrgu-FS, kuid see peegeldab täielikult asjade olemust. Selle optimeerimise negatiivne külg on kaasaskantavusprobleemid. Mõne jaoks võib viimane olla kriitiline. Näiteks GlusterFS-i tuumas pole üldse mooduleid. Tänu sellele töötab see nüüd paljudel platvormidel, sealhulgas NetBSD-l.
Milliseid kontseptsioone saaksid kohalikud FS-id võrgu omadelt laenata ja vastupidi?
Tänapäeval on võrgu FS-idel reeglina lisandmoodulid kohalikele FS-idele, nii et ma ei saa hästi aru, kuidas saab viimastelt midagi laenata. No tõesti, võtame 4 töötajaga ettevõtte, milles igaüks ajab oma asja: üks jagab, teine saadab, kolmas võtab vastu, neljas poetab. Ja küsimus, mida saab ettevõte laenata oma töötajalt, kes seda ladustab, kõlab kuidagi valesti (see on tal juba ammu olemas, mida ta oleks võinud temalt laenata).
Kuid kohalikel FS-idel on võrgu omadelt palju õppida. Esiteks peaksite neilt õppima, kuidas loogilisi mahtusid kõrgel tasemel koondada. Nüüd nn "Täiustatud" kohalikud failisüsteemid koondavad loogilisi köiteid eranditult LVM-ilt laenatud "virtuaalseadme" tehnoloogia abil (sama nakkav kihilisuse rikkumine, mis esmakordselt rakendati ZFS-is). Teisisõnu, virtuaalaadresside (plokinumbrite) tõlkimine päriseks ja tagasi toimub madalal tasemel (st pärast seda, kui failisüsteem on väljastanud I/O päringu).
Pange tähele, et seadmete lisamine ja eemaldamine plokikihile paigutatud loogilistele mahtudele (mitte peeglitele) põhjustab probleeme, millest selliste "funktsioonide" pakkujad tagasihoidlikult vaikivad. Ma räägin killustatusest päris seadmetes, mis võivad jõuda koletute väärtusteni, samas kui virtuaalseadmes on kõik hästi. Kuid vähesed inimesed tunnevad huvi virtuaalseadmete vastu: kõik on huvitatud sellest, mis toimub teie pärisseadmetes. Kuid ZFS-i sarnane FS (nagu ka mis tahes FS koos LVM-iga) töötab ainult virtuaalsete kettaseadmetega (eraldavad virtuaalse ketta aadressid vabade hulgast, defragmenteerivad need virtuaalsed seadmed jne). Ja neil pole aimugi, mis pärisseadmetes toimub!
Kujutage nüüd ette, et teil on virtuaalses seadmes null killustumine (st teil elab seal vaid üks hiiglaslik suurus), lisate oma loogilisse köitesse ketta ja seejärel eemaldate oma loogilisest köitest teise juhusliku ketta ja tasakaalustate seejärel uuesti. Ja nii mitu korda. Pole raske ette kujutada, et virtuaalses seadmes elate endiselt sama palju, kuid päris seadmetes ei näe te midagi head.
Kõige hullem on see, et te ei suuda seda olukorda isegi parandada! Ainus, mida siin teha saate, on paluda failisüsteemil virtuaalne seade defragmentida. Kuid ta ütleb teile, et seal on kõik suurepärane - on ainult üks ulatus, killustatus on null ja see ei saa olla parem! Seega ei ole ploki tasemel paigutatud loogilised helitugevused mõeldud seadmete korduvaks lisamiseks/eemaldamiseks. Heas mõttes on vaja ainult üks kord ploki tasemel loogiline köide kokku panna, see failisüsteemile anda ja siis sellega midagi muud teha.
Lisaks ei võimalda sõltumatute FS+LVM-i alamsüsteemide kombinatsioon võtta arvesse loogilisi mahtusid koondavate draivide erinevat olemust. Tõepoolest, oletame, et olete HDD-st ja pooljuhtseadmetest kokku pannud loogilise helitugevuse. Kuid siis esimene nõuab defragmentimist ja teine mitte. Viimase jaoks peate väljastama loobumistaotlused, kuid esimese jaoks mitte jne. Kuid selles kombinatsioonis on sellist selektiivsust üsna raske demonstreerida.
Pange tähele, et pärast failisüsteemis oma LVM-i loomist ei muutu olukord palju paremaks. Lisaks teete seda tehes tegelikult lõpu võimalusele seda tulevikus kunagi parandada. See on väga halb. Ühes masinas võivad töötada erinevat tüüpi draivid. Ja kui failisüsteem ei tee neil vahet, kes siis teeb?
Teine probleem on ootamas nn. "Write-Anywhere" failisüsteemid (see hõlmab ka Reiser4, kui määrasite ühendamise ajal sobiva tehingumudeli). Sellised failisüsteemid peavad pakkuma defragmentimise tööriistu, mille võimsus on enneolematu. Ja madala taseme helitugevuse haldur siin ei aita, vaid ainult segab. Fakt on see, et sellise halduriga salvestab teie FS ainult ühe seadme tasuta plokkide kaardi - virtuaalse. Sellest lähtuvalt saate defragmentida ainult virtuaalset seadet. See tähendab, et teie defragmentija töötab pikka, pikka aega tohutul üksikul virtuaalaadressil.
Ja kui teil on palju kasutajaid, kes teevad juhuslikke ülekirjutusi, siis sellise defragmentija kasulik mõju väheneb nullini. Teie süsteem hakkab paratamatult aeglustuma ja teil tuleb pettumust valmistava diagnoosi "katkine disain" ees vaid käed kokku panna. Mitmed samas aadressiruumis töötavad defragmentijad segavad ainult üksteist. Täiesti teine asi on see, kui säilitate iga päris seadme jaoks oma tasuta plokkide kaardi. See muudab defragmentimise protsessi tõhusalt paralleelseks.
Kuid seda saab teha ainult siis, kui teil on kõrgetasemeline loogiline helitugevuse haldur. Selliste halduritega kohalikke failisüsteeme varem ei eksisteerinud (vähemalt ma ei tea nende kohta). Sellised haldurid olid ainult võrgu failisüsteemidel (näiteks GlusterFS). Teine väga oluline näide on helitugevuse terviklikkuse kontrolli (fsck) utiliit. Kui salvestate iga alamköite jaoks iseseisva vabade plokkide kaardi, saab loogilise helitugevuse kontrollimise protseduuri tõhusalt paralleelstada. Teisisõnu, kõrgetasemeliste juhtidega loogilised mahud skaleeruvad paremini.
Lisaks ei saa te madala taseme helitugevuse halduritega korraldada täisväärtuslikke hetktõmmiseid. LVM-i ja ZFS-i sarnaste failisüsteemidega saate teha ainult kohalikke hetktõmmiseid, kuid mitte globaalseid pilte. Kohalikud hetktõmmised võimaldavad teil koheselt tagasi pöörata ainult tavalised failitoimingud. Ja keegi seal loogiliste mahtudega toiminguid tagasi ei keera (seadmete lisamine/eemaldamine). Vaatame seda näitega. Mingil ajahetkel, kui teil on kahe seadme A ja B loogiline maht, mis sisaldavad 100 faili, teete süsteemist S hetketõmmise ja loote seejärel veel sada faili.
Pärast seda lisate oma helitugevusele seadme C ja lõpuks taastate süsteemi, et saada S-hetktõmmis. Küsimus: Kui palju faile ja seadmeid sisaldab teie loogiline köide pärast tagasipööramist S-le? Faile on 100, nagu võite arvata, kuid seadmeid on 3 - need on samad seadmed A, B ja C, kuigi hetkepildi loomise ajal oli süsteemis ainult kaks seadet (A ja B ). Seadme C lisamise toiming ei kerinud tagasi ja kui eemaldate nüüd seadme C arvutist, rikub see teie andmeid, nii et enne kustutamist peate esmalt tegema kuluka toimingu, et eemaldada seade loogilisest tasakaalustamisest, mis hajutab kõik andmed seadmest C seadmetesse A ja B. Kuid kui teie FS toetab globaalseid hetktõmmiseid, poleks sellist tasakaalustamist vaja ja pärast kohest tagasipööramist S-le võite seadme C turvaliselt arvutist eemaldada.
Seega on globaalsed hetktõmmised head, kuna need võimaldavad teil vältida seadme kulukat eemaldamist (lisamist) suure andmemahuga loogilisest mahust (loogilisse köitesse) (muidugi, kui mäletate oma süsteemist "hetktõmmist"). õigel ajal). Lubage mul teile meelde tuletada, et hetktõmmiste loomine ja failisüsteemi tagasipööramine neile on hetkelised toimingud. Võib tekkida küsimus: kuidas on üldse võimalik loogilise mahuga operatsioon, mis võttis kolm päeva, kohe tagasi kerida? Aga see on võimalik! Eeldusel, et teie failisüsteem on õigesti loodud. Selliste “3D-hetketõmmiste” idee tuli mul välja kolm aastat tagasi ja eelmisel aastal patenteerisin selle tehnika.
Järgmine asi, mida kohalikud FS-id võrgu omadelt õppima peaksid, on metaandmete salvestamine eraldi seadmetesse samamoodi, nagu võrgu FS-id salvestavad neid eraldi masinatesse (nn metaandmete serveritesse). On rakendusi, mis töötavad peamiselt metaandmetega ja neid rakendusi saab oluliselt kiirendada, paigutades metaandmed kallitele suure jõudlusega salvestusseadmetele. Kombinatsiooniga FS+LVM ei saa te sellist selektiivsust demonstreerida: LVM ei tea, mis on plokis, mille te talle edastasite (seal olevad andmed või metaandmed).
Võrreldes FS+LVM kombinatsiooniga ei saa te oma madala taseme LVM-i juurutamisest FS-is erilist kasu, kuid väga hästi saate FS-i segamini ajada, nii et hiljem muutub selle koodiga töötamine võimatuks. Virtuaalsete seadmetega tormanud ZFS ja Btrfs on kõik selged näited sellest, kuidas kihilisuse rikkumine tapab süsteemi arhitektuurilises mõttes. Miks ma siis kõik see olen? Lisaks pole vaja failisüsteemi installida oma madala taseme LVM-i. Selle asemel peate seadmed koondama kõrgel tasemel loogilistesse mahtudesse, nagu teevad mõned võrgufailisüsteemid erinevate masinatega (salvestussõlmed). Tõsi, nad teevad seda vastikult halbade algoritmide kasutamise tõttu.
Täiesti kohutavate algoritmide näideteks on GlusterFS-i failisüsteemis DHT-tõlk ja Ceph failisüsteemis nn CRUSH-kaart. Ükski algoritm, mida ma nägin, ei rahuldanud mind lihtsuse ja hea mastaapsuse poolest. Seega tuli algebra meeles pidada ja kõik ise välja mõelda. 2015. aastal räsifunktsioonide üle kimpudega katsetades mõtlesin välja ja patenteerisin midagi, mis mulle sobib. Nüüd võin öelda, et katse seda kõike ellu viia õnnestus. Ma ei näe uues lähenemisviisis skaleeritavusega probleeme.
Jah, iga alamköide vajab eraldi struktuuri, näiteks superplokki mälus. Kas see on väga hirmutav? Üldiselt ma ei tea, kes hakkab "ookeani keema" ja looma ühes kohalikus masinas sadade tuhandete või enama seadmete loogilisi mahtusid. Kui keegi oskab seda mulle selgitada, oleksin väga tänulik. Vahepeal on see minu jaoks turunduslik jama.
Kuidas mõjutasid muudatused kerneliploki seadme alamsüsteemis (näiteks blk-mq ilmumine) FS-i juurutamise nõudeid?
Neil ei olnud mingit mõju. Ma ei tea, mis juhtuks plokikihiga, mis muudaks vajalikuks uue FS-i kujundada. Nende alamsüsteemide interaktsiooniliides on väga halb. Draiveri poolelt peaks FS-i mõjutama ainult uut tüüpi draivide ilmumine, millele kohandatakse kõigepealt plokikiht ja seejärel FS (reiser4 jaoks tähendab see uute pluginate ilmumist).
Kas uut tüüpi meediumitüüpide (näiteks SMR või SSD-de üldlevinud) ilmumine tähendab failisüsteemi kujundamisel põhimõtteliselt uusi väljakutseid?
Jah. Ja need on normaalsed stiimulid FS-i arendamiseks. Väljakutsed võivad olla erinevad ja täiesti ootamatud. Näiteks olen kuulnud draividest, kus I/O toimingu kiirus sõltub suuresti andmetüki suurusest ja selle nihkest. Linuxis, kus FS-i ploki suurus ei saa ületada lehe suurust, ei näita selline draiv vaikimisi oma kõiki võimalusi. Kui aga teie failisüsteem on õigesti kujundatud, on võimalus sellest palju rohkem kasu saada.
Kui palju inimesi peale teie praegu Reiser4 koodiga töötab?
Vähem, kui tahaks, aga teravat ressursipuudust ei tunne ka. Olen Reiser4 arengutempoga enam kui rahul. Ma ei hakka "hobustega sõitma" - see pole õige ala. Siin: "Kui sõidate vaiksemalt, siis jätkate!" Kaasaegne failisüsteem on kõige keerulisem kerneli alamsüsteem, mille valed disainiotsused võivad tühistada järgnevate aastate inimtöö.
Pakkudes vabatahtlikke millegi elluviimiseks, garanteerin alati, et pingutused viivad kindlasti õige tulemuseni, mida võib tõsiste vajaduste korral nõuda. Nagu aru saate, ei saa selliseid garantiisid korraga palju olla. Samal ajal ei talu ma "figuure", kes reklaamivad häbematult ilmselgelt kasutuskõlbmatu tarkvara "funktsioone", pettes sadu kasutajaid ja arendajaid ning samal ajal istuvad ja naeratavad kerneli tippkohtumistel.
Kas mõni ettevõte on avaldanud soovi toetada Reiser4 arendamist?
Jah, selliseid ettepanekuid oli, sh. ja suurelt müüjalt. Kuid selleks pidin kolima teise riiki. Kahjuks pole ma enam 30-aastane, ma ei saa esimese vile peale niimoodi lahku minna ja lahkuda.
Millised funktsioonid Reiser4-st praegu puuduvad?
Lihtsate köidete jaoks pole suuruse muutmise funktsiooni, mis on sarnane ReiserFS(v3) funktsioonile. Lisaks ei kahjustaks failitoimingud lipuga DIRECT_IO. Järgmisena sooviksin, et oleks võimalik eraldada köide "semantilisteks alamköideteks", millel ei ole kindlat suurust ja mida saab paigaldada iseseisvate köidetena. Need probleemid on head algajatele, kes soovivad proovida kätt "päris asjas".
Ja lõpetuseks tahaksin endale lihtsa juurutamise ja administreerimisega võrguloogilisi köiteid (kaasaegsed algoritmid juba võimaldavad seda). Mida aga Reiser4-l kindlasti kunagi ei tule, on RAID-Z, puhastused, vaba ruumi vahemälud, 128-bitised muutujad ja muu turunduslik jama, mis tekkis mõne failisüsteemi arendajate ideede nappuse taustal.
Kas pistikprogrammide abil saab rakendada kõike, mida võib vaja minna?
Kui rääkida ainult liidestest ja neid realiseerivatest pluginatest (moodulitest), siis mitte kõigest. Aga kui nendel liidestel tutvustada ka seoseid, siis on muuhulgas ka kõrgemate polümorfismide mõisted, millega saad juba hakkama. Kujutage ette, et külmutasite hüpoteetiliselt objektorienteeritud käitussüsteemi, muutsite käsukursori väärtust, et osutada teisele sama X-liidest rakendavale pistikprogrammile, ja seejärel vabastasite süsteemi, et see jätkaks täitmist.
Kui lõppkasutaja sellist "asendust" ei märka, siis ütleme, et süsteemil on X-liideses nulljärku polümorfism (või on süsteem X-liideses heterogeenne, mis on sama asi). Kui teil pole nüüd mitte ainult liideste komplekt, vaid neil on ka seoseid (liidesegraafik), saate tutvustada kõrgema järgu polümorfisme, mis iseloomustavad süsteemi heterogeensust juba mis tahes liidese "naabruses". Võtsin sellise klassifikatsiooni kasutusele juba ammu, kuid kahjuks ei juhtunud seda kunagi.
Nii saate pistikprogrammide ja selliste kõrgemate polümorfismide abil kirjeldada mis tahes tuntud omadusi, aga ka "ennustada" neid, mida pole kunagi isegi mainitud. Ma ei ole suutnud seda rangelt tõestada, kuid ma ei tea veel ka vastunäidet. Üldiselt meenutas see küsimus mulle Felix Kleini “Erlangeni programmi”. Korraga püüdis ta kujutada kogu geomeetriat algebra (täpsemalt rühmateooria) haruna.
Nüüd põhiküsimuse juurde – kuidas läheb Reiser4 põhituumiku promomisega? Kas selle failisüsteemi arhitektuuri kohta oli väljaandeid, millest viimases intervjuus rääkisite? Kui asjakohane see küsimus teie vaatenurgast on?
Üldiselt oleme põhiharusse kaasamist taotlenud kolm aastat. Reiseri viimane kommentaar avalikus lõimes, kus tõmbamistaotlus esitati, jäi vastuseta. Seega pole kõik edasised küsimused meie jaoks. Ma isiklikult ei saa aru, miks me peame "liitma" konkreetse operatsioonisüsteemiga. Linuxis ei koondunud valgus nagu kiilu. Seega on olemas eraldi hoidla, milles on erinevate OS-ide jaoks mitu haruporti. Kellel vaja, saab kloonida vastava pordi ja teha sellega mida tahad (litsentsi piires muidugi). Noh, kui keegi seda ei vaja, pole see minu probleem. Siinkohal teen ettepaneku käsitleda Linuxi põhituuma edendamise küsimust lahendatuks.
FS-arhitektuuri käsitlevad publikatsioonid on asjakohased, kuid seni olen leidnud aega vaid oma uute tulemuste jaoks, mida pean prioriteetsemaks. Teine asi on see, et ma olen matemaatik ja matemaatikas on igasugune väljaanne teoreemide ja nende tõestuste kokkuvõte. Seal ilma tõenditeta millegi avaldamine on märk halvast maitsest. Kui ma mõne väite FS-i arhitektuuri kohta põhjalikult tõestan või ümber lükkan, siis on tulemuseks sellised kuhjad, millest on üsna raske läbi saada. Kellele seda vaja on? Ilmselt seetõttu jääbki kõik endisele kujule – lähtekood ja kommentaarid sellele.
Mida on Reiser4-s viimaste aastate jooksul uut olnud?
Kauaoodatud stabiilsus on lõpuks realiseerunud. Üks viimastest, mis ilmus, oli viga, mis viis kustutamatute kataloogideni. Raskus seisnes selles, et see ilmus ainult nimede räsipõrgete taustal ja kataloogikirjete teatud asukohaga puusõlmes. Siiski ei saa ma endiselt Reiser4 tootmiseks soovitada: selleks peate tegema natuke tööd koos aktiivse suhtlusega tootmissüsteemide administraatoritega.
Lõpuks õnnestus meil ellu viia oma kauaaegne idee - erinevad tehingumudelid. Varem kasutas Reiser4 ainult ühte kõvakoodiga Macdonald-Reiseri mudelit. See tekitas disainiprobleeme. Eelkõige ei ole sellises tehingumudelis hetktõmmised võimalikud - need rikub aatomikomponent nimega "OVERWRITE SET". Reiser4 toetab praegu kolme tehingumudelit. Ühes neist (Write-Anywhere) sisaldab aatomikomponent OVERWRITE SET ainult süsteemilehti (ketta bitmap-ide pildid jne), mida ei saa “pildistada” (kana ja muna probleem).
Nii et pilte saab nüüd realiseerida parimal võimalikul viisil. Teises tehingumudelis lähevad kõik muudetud lehed ainult ÜLEKIRJUTAMISEKS (see tähendab, et see on sisuliselt puhas ajakirjandus). See mudel on mõeldud neile, kes kaebasid Reiser4 partitsioonide kiire killustumise üle. Nüüd selles mudelis ei killu partitsioon kiiremini kui ReiserFS (v3) puhul. Kõik kolm olemasolevat mudelit tagavad teatud reservatsioonidega operatsioonide atomaalsuse, kuid kasulikud võivad olla ka mudelid, millel on atomaalsuse kadu ja säilitatakse ainult sektsiooni terviklikkus. Sellised mudelid võivad olla kasulikud igasuguste rakenduste jaoks (andmebaasid jne), mis on juba mõne neist funktsioonidest võtnud. Neid mudeleid on Reiser4-sse väga lihtne lisada, kuid ma ei teinud seda, sest keegi ei küsinud minult ja mul pole seda isiklikult vaja.
Ilmusid metaandmete kontrollsummad ja hiljuti täiendasin neid “ökonoomsete” peeglitega” (ikka ebastabiilne materjal). Kui mõne ploki kontrollsumma ebaõnnestub, loeb Reiser4 kohe vastava ploki koopiaseadmest. Pange tähele, et ZFS ja Btrfs ei saa seda teha: disain ei võimalda seda. Seal peate käivitama spetsiaalse tausta skannimise protsessi nimega "scrub" ja ootama, kuni see probleemsesse plokki jõuab. Programmeerijad nimetavad selliseid sündmusi piltlikult "karkudeks".
Ja lõpuks on ilmunud heterogeensed loogikaköidud, mis pakuvad kõike seda, mida ZFS, Btrfs, plokkkiht, aga ka FS+LVM kombinatsioonid põhimõtteliselt pakkuda ei suuda - paralleelne skaleerimine, O(1) kettaaadresside eraldaja, läbipaistev andmete migratsioon alamköidete vahel. Viimasel on ka kasutajaliides. Nüüd saate hõlpsalt teisaldada kuumimad andmed oma helitugevuse kõige võimsamale draivile.
Lisaks on võimalik kiiresti loputada kõik määrdunud lehed sellisele draivile, kiirendades sellega märkimisväärselt rakendusi, mis sageli kutsuvad fsync(2). Märgin, et plokikihi funktsionaalsus, mida nimetatakse bcache'iks, ei anna üldse sellist tegevusvabadust. Uued loogikaköited põhinevad minu algoritmidel (vastavad patendid on olemas). Tarkvara on juba üsna stabiilne, seda on täiesti võimalik proovida, jõudlust mõõta jne. Ainus ebamugavus on see, et praegu peate helitugevuse konfiguratsiooni käsitsi värskendama ja kuskile salvestama.
Siiani olen suutnud oma ideid ellu viia 10 protsenti, kuid mul on õnnestunud see, mida pidasin kõige keerulisemaks - loogiliste mahtude ühendamine välkprotseduuriga, mis teostab kõik edasilükatud toimingud reiser4-s. See kõik on endiselt eksperimentaalses "format41" harus.
Kas Reiser4 läbib xfstestid?
Vähemalt minu jaoks oli see nii, kui ma viimast väljaannet ette valmistasin.
Kas Reiser4 on põhimõtteliselt võimalik teha pluginaid kasutades võrgu (klastri) FS?
See on võimalik ja isegi vajalik! Kui loote võrgufaili õigesti kavandatud kohalikul failisüsteemil, on tulemus väga muljetavaldav! Kaasaegsetes võrgu-FS-ides ei ole ma rahul taustasalvestustaseme olemasoluga, mida rakendatakse mis tahes kohaliku FS-i abil. Selle taseme olemasolu on täiesti põhjendamatu. Võrgu FS peab suhtlema otse plokikihiga, mitte paluma kohalikul FS-il luua muid teenusefaile!
Üldiselt on failisüsteemide jagamine kohalikuks ja võrguks kurjast. See tekkis kolmkümmend aastat tagasi kasutatud algoritmide ebatäiuslikkusest, mille asemele pole veel midagi välja pakutud. See on ka põhjus ebavajalike tarkvarakomponentide (erinevad teenused jne) massi ilmumiseks. Heas mõttes peaks igasse masinasse olema installitud ainult üks FS kerneli mooduli kujul ja kasutaja utiliitide komplekt - klastri sõlm. See FS on nii kohalik kui ka võrk. Ja ei midagi enamat!
Kui Linuxis Reiser4-ga midagi ei õnnestu, tahaksin pakkuda FS-i FreeBSD jaoks (tsitaat eelmisest intervjuust: “...FreeBSD... on akadeemiliste juurtega... Ja see tähendab, et suure tõenäosusega me leiab arendajatega ühise keele"?
Niisiis, nagu just avastasime, on Linuxiga kõik juba suurepäraselt toiminud: selle jaoks on eraldi töötav Reiser4 port meie hoidla põhiharu kujul. Ma pole FreeBSD-d unustanud! Pakkumine! Olen valmis tegema tihedat koostööd nendega, kes tunnevad hästi FreeBSD sisemust. Muide: mulle nende kogukonna juures väga meeldib, et seal teeb otsuseid uuendatud sõltumatute ekspertide nõukogu, millel pole mingit pistmist ühe alalise inimese valitsuse petmisega.
Kuidas hindate tänast Linuxi kasutajate kogukonda? Kas see on muutunud "popimaks"?
Minu töö iseloomu arvestades on mul seda üsna raske hinnata. Enamasti tulevad kasutajad minu poole veaaruannete ja taotlustega jaotise parandamiseks. Kasutajad kui kasutajad. Mõni on targem, mõni vähem. Kõiki koheldakse ühtemoodi. No kui kasutaja minu juhiseid eirab, siis vabandage: ignoreerimiskäsk sisestatakse ka minu poolt.
Kas failisüsteemide arengut on võimalik ennustada järgmiseks viieks kuni kümneks aastaks? Mis on teie arvates peamised väljakutsed, millega FS-i arendajad silmitsi võivad tulla?
Jah, sellist prognoosi pole keeruline teha. Ülesvoolus pole failisüsteemide arendamist pikka aega olnud. Luuakse vaid sellise välimus. Kohalike failisüsteemide arendajatel tekkisid halva disainiga seotud probleemid. Siin tuleb teha hoiatus. Ma ei pea koodi nn salvestamist, lakkumist ja teisaldamist arendamiseks ja arendamiseks. Ja ma ei liigita "Btrfs"-nimelist arusaamatust arenguks põhjustel, mida olen juba selgitanud.
Iga plaaster muudab selle probleemid ainult hullemaks. Noh. ja alati leidub mitmesuguseid "evangeliste", kelle jaoks "kõik töötab". Põhimõtteliselt on need kooliõpilased ja üliõpilased, kes jätavad loenguid vahele. Kujutage vaid ette: see töötab tema jaoks, kuid professor mitte. Milline adrenaliinilaks see on! Minu seisukohalt tekitavad suurimat kahju “käsitöölised”, kes tormasid entusiastlikult Btrfsi imelisi omadusi kõikvõimalikele kihtidele nagu systemd, docker jne peale “kruvima”. - see meenutab juba metastaase.
Proovime nüüd teha prognoosi viieks kuni kümneks aastaks. Olen juba lühidalt loetlenud, mida me Reiser4-s teeme. Kohalike FS-i arendajate peamiseks väljakutseks ülesvoolust saab (jah, see on juba saanud) suutmatus teha korralikku tööd palga eest. Ilma igasuguste ideedeta andmesalvestuse vallas jätkavad nad nende õnnetute VFS-i, XFS-i ja ext4 lappimist. Olukord VFS-iga tundub sellel taustal eriti koomiline, meenutades meeletut moderniseerimist restoranis, kus kokkasid pole ja kokki pole oodata.
Nüüd lukustab VFS-kood ilma igasuguste tingimusteta mitu mälulehte korraga ja kutsub aluseks oleva FS-i nendega töötama. See võeti kasutusele Ext4 jõudluse parandamiseks kustutamisoperatsioonidel, kuid nagu on lihtne mõista, on selline samaaegne lukustamine täiustatud tehingumudelitega täiesti vastuolus. See tähendab, et te ei saa lihtsalt lisada tuuma mõne nutika failisüsteemi tuge. Ma ei tea, milline on olukord Linuxi teistes valdkondades, aga mis puutub failisüsteemidesse, siis tõenäoliselt ei sobi siinne arendus Torvaldsi praktikas järgitava poliitikaga (akadeemilised projektid visatakse välja ja petturid, kes pole õrna aimugi, mis on B-puu, väljastatakse lõputuid usalduskrediite). Seetõttu pandi kurssi aeglasele lagunemisele. Muidugi püüavad nad kogu oma jõuga seda "arenguks" edasi anda.
Lisaks proovivad failisüsteemide “hooldajad”, saades aru, et ainuüksi “salvestusega” palju teenida ei saa, proovivad kätt tulusamas äris. Need on reeglina hajutatud failisüsteemid ja virtualiseerimine. Võib-olla viivad nad moeka ZFS-i mujale, kus seda veel pole. Kuid see, nagu kõik ülesvoolu FS-id, meenutab uusaastapuud: kui saate riputada muid pisiasju, siis ei saa te enam sügavamale. Möönan, et ZFS-i baasil on võimalik ehitada tõsiseltvõetav ettevõtte süsteem, kuid kuna praegu arutleme tuleviku üle, siis võin kurvalt tõdeda, et ZFS on selles osas lootusetu: tüübid on oma virtuaalseadmetega hapniku ära lõiganud. endale ja tulevastele põlvedele edasiseks arenguks. ZFS on minevik. Ja ext4 ja XFS pole isegi üleeile.
Eraldi tasub mainida sensatsioonilist kontseptsiooni "järgmise põlvkonna Linuxi failisüsteem". See on täiesti poliitiline ja turundusprojekt, mis on loodud võimaluseks nii-öelda "kinnitada failisüsteemide tulevik" Linuxis kindlate märkide taha. Fakt on see, et Linux oli varem "lihtsalt lõbu pärast". Nüüd on see aga eelkõige rahateenimismasin. Need on valmistatud kõigest võimalikust. Näiteks head tarkvaratoodet on väga raske luua, aga nutikad “arendajad” on juba ammu aru saanud, et pingutada pole vaja: saab edukalt müüa olematut tarkvara, mida kõikvõimalikel avalikkusel välja kuulutati ja reklaamiti. sündmused - peamine on see, et esitlusslaidid peaksid sisaldama rohkem "funktsioone".
Failisüsteemid sobivad selleks suurepäraselt, sest tulemusega võib julgelt kümme aastat kaubelda. Noh, kui keegi hiljem kaebab just selle tulemuse puudumise üle, siis ta lihtsalt ei saa failisüsteemidest midagi aru! See meenutab finantspüramiidi: tipus on seiklejad, kes selle jama algatasid, ja need vähesed, kellel “vedas”: nemad “võtsid dividende välja”, s.t. sai arendusraha, sai hästi tasustatud töökoha juhtidena, “esitas” konverentsidel jne.
Järgmiseks tulevad need, kellel pole õnne: nad arvestavad kahjusid, tegelevad kasutuskõlbmatu tarkvaratoote tootmisse juurutamise tagajärgedega jne. Neid on palju rohkem. Noh, püramiidi põhjas on tohutu hulk arendajaid, kes “saagivad” kasutut koodi. Nemad on suurimad kaotajad, sest raisatud aega tagasi ei saa. Sellised püramiidid on Torvaldsile ja tema kaaslastele äärmiselt kasulikud. Ja mida rohkem neid püramiide, seda parem neile. Selliste püramiidide toitmiseks võib südamikusse võtta kõike. Muidugi räägivad nad avalikult vastupidist. Kuid ma hindan mitte sõnade, vaid tegude järgi.
Niisiis on "Linux-failisüsteemide tulevik" veel üks kõrgelt reklaamitud, kuid vaevalt kasutatav tarkvara. Pärast Btrfsi võtab sellise “tuleviku” koha suure tõenäosusega sisse Bcachefs, mis on järjekordne katse Linuxi plokikihti failisüsteemiga ületada (halb näide on nakkav). Ja mis on tüüpiline: seal on samad probleemid, mis Btrfsis. Kahtlustasin seda pikka aega ja siis kuidagi ei suutnud ma vastu panna ja uurisin koodi - see on tõsi!
Bcachefi ja Btrfsi autorid kasutasid oma FS-i loomisel aktiivselt teiste inimeste allikaid, saades neist vähe aru. Olukord meenutab väga lastemängu “katkine telefon”. Ja ma kujutan umbkaudu ette, kuidas see kood kernelisse kaasatakse. Tegelikult ei näe “rehasid” keegi (hiljem astuvad neile peale). Pärast arvukaid segadusi koodi stiili üle, süüdistusi olematutes rikkumistes jms tehakse järeldus autori “lojaalsuse” kohta, kui hästi ta teiste arendajatega “suhtleb” ja kui edukalt see kõik õnnestub. seejärel müüa korporatsioonidele.
Lõpptulemus ei huvita kedagi. 20 aastat tagasi oleks võib-olla huvi tundnud, aga nüüd esitatakse küsimusi teisiti: kas seda on võimalik edendada nii, et järgmise kümne aasta jooksul saaks teatud inimesed tööle. Ja paraku pole kombeks lõpptulemuse üle imestada.
Üldiselt soovitan tungivalt mitte alustada oma failisüsteemi nullist uuesti leiutamist. Sest isegi märkimisväärsetest finantsinvesteeringutest ei piisa, et kümne aasta pärast midagi konkurentsivõimelist saada. Loomulikult räägin ma tõsistest projektidest, mitte neist, mis on mõeldud tuumasse "surumiseks". Nii et tõhusam viis ennast väljendada on ühineda reaalsete arengutega, nagu meie. Seda pole muidugi lihtne teha – aga nii on iga kõrgetasemelise projekti puhul.
Esiteks peate iseseisvalt ületama probleemi, mille ma pakun. Pärast seda, olles teie kavatsuste tõsiduses veendunud, hakkan aitama. Traditsiooniliselt kasutame ainult enda arendusi. Erandiks on tihendusalgoritmid ja mõned räsifunktsioonid. Me ei saada arendajaid konverentsidele reisima ja siis me ei istu ja ei kombineeri teiste inimeste ideid ("võib-olla mis juhtub"), nagu enamiku idufirmade puhul tavaks.
Kõik algoritmid töötame välja ise. Olen praegu huvitatud andmete salvestamise teaduse algebralistest ja kombinatoorsetest aspektidest. Eelkõige lõplikud väljad, asümptootika, ebavõrdsuse tõestus. Tööd on ka tavaliste programmeerijate jaoks, kuid pean teid kohe hoiatama: kõiki soovitusi "vaadake teist FS-i ja tehke sama" eiratakse. Sinna lähevad ka paigad, mille eesmärk on VFS-i kaudu Linuxiga tihedam integreerida.
Niisiis, meil pole reha, kuid meil on arusaam, kuhu peame liikuma, ja oleme kindlad, et see suund on õige. See arusaam ei tulnud taevamanna kujul. Tuletan meelde, et meil on seljataga 29 aastat arenduskogemust, kaks nullist kirjutatud failisüsteemi. Ja sama palju andmete taastamise utiliite. Ja seda on palju!
Allikas: opennet.ru