Die tweede onderhoud met Eduard Shishkin, ontwikkelaar van die Reiser4-lêerstelsel, is gepubliseer.
Om te begin, herinner asseblief lesers waar en vir wie jy werk.
Ek werk as 'n hoofbergingsargitek by Huawei Technologies, Duitse navorsingsentrum. In die virtualisasie-afdeling hanteer ek verskeie aspekte van databerging. My aktiwiteite hou nie verband met 'n spesifieke bedryfstelsel nie.
Verbind jy jou tans tot die hoofkerntak?
Baie selde, en slegs as my werkgewer dit vereis. Die laaste keer was ongeveer drie jaar gelede, ek het pleisters gestuur om die deurset te verhoog vir berging wat op gashere gedeel word met behulp van die 9p-protokol ('n ander naam vir hierdie besigheid is VirtFS). Een belangrike nota moet hier gemaak word: alhoewel ek al lank met Linux werk, was ek nog nooit 'n aanhanger daarvan nie, dit wil sê ek "asem eweredig asem", soos met alles anders. Veral as ek 'n fout opmerk, kan ek dit hoogstens een keer uitwys. En sodat jy dan iemand kan volg en oorreed – dit sal nie gebeur nie.
Ek onthou laas keer, tien jaar gelede, was jy nogal krities oor die kernontwikkelingstyl. Vanuit jou (of dalk korporatiewe) oogpunt, het enigiets verander, het die gemeenskap meer responsief geword of nie? Indien nie, wie dink jy is te blameer?
Ek het nooit enige veranderinge ten goede gesien nie. Die hoofprobleem van die gemeenskap is die vervanging van wetenskap met politieke tegnologieë, persoonlike verhoudings, meerderheidsmening, populisme, advies van “innerlike stemme,” vrot kompromieë, enigiets anders as wetenskap. Rekenaarwetenskap, wat mens ook al mag sê, is in die eerste plek 'n presiese wetenskap. En as iemand hul eie waarde vir 2x2, anders as 4, onder die "Linux-weg"-vlag, of onder 'n ander vlag begin verkondig, dan is dit onwaarskynlik dat dit enigiets anders as skade sal bring.
Alle probleme is hoofsaaklik te wyte aan die onbevoegdheid en gebrek aan opvoeding van diegene wat besluite neem. As 'n bestuurder onbevoeg is, is hy nie in staat om 'n objektiewe, toereikende besluit te neem nie. As hy ook onkultuur is, kry hy nie 'n bekwame spesialis wat hom die regte raad sal gee nie. Met 'n hoë waarskynlikheid sal die keuse op 'n swendelaar val wat "oënskynlik korrekte dinge" sê. ’n Korrupte omgewing ontwikkel altyd rondom onbevoegde alleenleiers. Boonop ken die geskiedenis geen uitsonderings in hierdie verband nie, en die gemeenskap is die duidelikste bevestiging hiervan.
Hoe beoordeel jy die vordering in Btrfs-ontwikkeling? Het hierdie FS ontslae geraak van kindersiektes? Hoe posisioneer jy dit vir jouself - as 'n FS "vir die huis" of vir korporatiewe gebruik ook?
Ek het nie daarvan ontslae geraak nie. Alles wat ek 11 jaar gelede genoem het, is vandag steeds relevant. Een van die probleme met Btrfs wat dit ongeskik maak vir ernstige behoeftes, is die probleem van vrye spasie. Ek praat nie eers van die feit dat die gebruiker gevra word om na die winkel te hardloop vir 'n nuwe skyf in situasies waar enige ander FS baie vrye spasie op die partisie sal wys nie. Die onvermoë om 'n operasie op 'n logiese volume te voltooi weens 'n gebrek aan vrye spasie is ook nie die ergste ding nie. Die ergste is dat 'n onbevoorregte gebruiker feitlik altyd enige skyfkwotas kan omseil, almal van vrye spasie in 'n redelike kort tyd kan ontneem.
Dit lyk so (getoets vir Linux-kern 5.12). 'n Skrip word op 'n vars geïnstalleerde stelsel geloods, wat in 'n lus lêers met sekere name in die tuisgids skep, data aan hulle skryf teen sekere afwykings, en dan hierdie lêers uitvee. Na 'n minuut van hierdie draaiboek gebeur niks ongewoons nie. Na vyf minute neem die gedeelte van die besette spasie op die partisie effens toe. Na twee tot drie uur bereik dit 50% (met 'n beginwaarde van 15%). En na vyf of ses uur se werk val die skrif neer met die fout "daar is geen vrye spasie op die partisie nie." Hierna is jy nie meer in staat om selfs 'n 4K-lêer na jou partisie te skryf nie.
'n Interessante situasie vind plaas: jy het uiteindelik niks aan die partisie geskryf nie, en al die vrye spasie (ongeveer 85%) het iewers verdwyn. Ontleding van 'n gedeelte wat onderhewig is aan so 'n aanval sal baie boomnodusse openbaar wat net een item bevat ('n voorwerp toegerus met 'n sleutel), verskeie grepe groot. Dit wil sê, die inhoud wat voorheen 15% van die skyfspasie beslaan het, blyk eweredig oor die hele partisie te "gesmeer" sodat daar nêrens is om 'n nuwe lêer te skryf nie, want die sleutel is groter as alle bestaandes, en die gratis blokke op die partisie het opgeraak.
Boonop gebeur dit alles reeds op die basiese Btrfs-konfigurasie (sonder enige foto's, subvolumes, ens.), en dit maak nie saak hoe jy besluit om lêerliggame in daardie FS te stoor nie (as "fragmente" in 'n boom, of as omvang van ongeformateerde blokke) - die eindresultaat sal dieselfde wees.
Jy sal nie ander stroomop-lêerstelsels aan so 'n aanval kan onderwerp nie (maak nie saak wat hulle vir jou sê nie). Ek het lank gelede die oorsaak van die probleem verduidelik: dit is 'n volledige verdraaiing van die B-boom-konsep in Btrfs, wat dit moontlik maak dat dit spontaan of doelbewus ontaard. In die besonder, onder sekere vragte, sal jou lêerstelsel voortdurend "uitmekaar val" tydens werking op sy eie, sonder hulp van buite. Dit is duidelik dat allerhande "druk" agtergrondprosesse die dag net op individuele rekenaars sal red.
Op kollektiewe bedieners sal 'n aanvaller hulle altyd "voor" kan kry. Die stelseladministrateur sal nie eers kan vasstel wie hom presies geboelie het nie. Die vinnigste manier om hierdie probleem in Btrfs op te los, is om die struktuur van 'n gewone B-boom te herstel, m.a.w. herontwerp van die skyfformaat en die herskryf van beduidende gedeeltes van die Btrfs-kode. Dit sal 8-10 jaar neem, insluitend ontfouting, mits die ontwikkelaars die oorspronklike artikels oor die relevante algoritmes en datastrukture streng gevolg het, en nie die "gebroke foon"-speletjie gespeel het nie, soos gebruiklik (en aangemoedig word) in die "Linux". manier”.
Hier moet ons ook die tyd byvoeg wat nodig is vir ontwikkelaars om dit alles te verstaan. Dit is hier waar dit moeiliker word. In elk geval, 10 jaar was nie genoeg vir hulle om te verstaan nie. Wel, tot dan kan jy nie op 'n wonderwerk hoop nie. Dit sal nie gebeur in die vorm van 'n monteeropsie "waarvan ek en jy nie geweet het nie," of in die vorm van 'n pleister wat "net 'n saak van besigheid" is om voor te berei nie. Vir elke so 'n haastige "fix" sal ek 'n nuwe scenario van degenerasie aanbied. B-bome is een van my gunsteling onderwerpe, en ek moet sê dat hierdie strukture nie vryhede met hulself duld nie!
Hoe posisioneer ek Btrfs vir myself? As iets wat absoluut nie 'n lêerstelsel genoem kan word nie, wat nog te sê gebruik. Omdat, per definisie, die FS 'n OS-substelsel is wat verantwoordelik is vir die effektiewe bestuur van die "skyfspasie"-hulpbron, wat ons nie in die geval van Btrfs sien nie. Wel, stel jou voor dat jy winkel toe gekom het om 'n horlosie te koop om nie laat te wees vir werk nie, en in plaas van 'n horlosie het hulle vir jou 'n elektriese rooster met 'n timer vir 'n maksimum van 30 minute verkoop. Dus, die situasie met Btrfs is selfs erger.
As ek deur poslyste kyk, kom ek dikwels op die stelling af dat die doeltreffende bestuur van skyfspasie nie meer relevant is nie as gevolg van die goedkoopheid van aandrywers. Dit is totale onsin. Sonder 'n effektiewe skyfspasiebestuurder sal die bedryfstelsel kwesbaar en onbruikbaar word. Ongeag die kapasiteit van die skywe op jou masjien.
Ek wil graag kommentaar vra oor die staking van Btrfs-ondersteuning in RHEL.
Hier is niks besonders om op kommentaar te lewer nie, alles is baie duidelik. Hulle het dit ook as 'n "tegnologievoorskou" gehad. So, ek het nie deur hierdie einste "voorskou" gegaan nie. Moenie dat hierdie etiket vir ewig hang nie! Maar hulle kan nie 'n gebrekkige ontwerpproduk met volle ondersteuning bekendstel nie. RHEL is 'n onderneming, dit wil sê, voorgeskrewe kommoditeit-geldverhoudings. Red Hat kan nie gebruikers boelie soos hulle op die Btrfs-poslys doen nie. Stel jou net die situasie voor: 'n kliënt wat sy swaarverdiende geld vir die skyf betaal het en ook jy vir ondersteuning, wil verstaan waar sy skyfspasie gegaan het nadat hy niks neergeskryf het nie. Wat sal jy hom hierop antwoord?
Verder. Red Hat se kliënte sluit bekende groot banke en beurse in. Stel jou voor wat sou gebeur as hulle onderhewig was aan DoS-aanvalle gebaseer op die genoemde kwesbaarheid in Btrfs. Wie dink jy is verantwoordelik hiervoor? Vir diegene wat op die punt staan om hul vinger na die lyn van die GPL-lisensie te wys, waar geskryf staan dat die skrywer vir niks verantwoordelik is nie, sal ek dadelik sê: “steek dit weg!” Red Hat sal antwoord, en op so 'n manier dat dit nie genoeg sal lyk nie! Maar ek weet dat Red Hat nie hierdie soort probleem in die gesig staar nie, gegewe hul besonder sterk span QA-ingenieurs met wie ek die geleentheid gehad het om nou saam te werk in my tyd.
Waarom gaan sommige maatskappye voort om Btrfs in hul ondernemingsprodukte te ondersteun?
Neem asseblief kennis dat die voorvoegsel "onderneming" in die produknaam nie veel beteken nie. Onderneming is 'n maatstaf van verantwoordelikheid wat in die kontraktuele verhouding met die kliënt ingebed is. Ek weet van slegs een onderneming gebaseer op GNU/Linux - RHEL. Alles anders word uit my oogpunt net as 'n onderneming voorgestel, maar is nie een nie. En laastens, as daar 'n vraag na iets is, dan sal daar altyd 'n aanbod wees (in ons geval is dit die genoemde "ondersteuning"). Daar is vraag na absoluut alles, inkl. en onbruikbare sagteware. Hoe so 'n aanvraag gevorm word en wie dit aanvuur, is 'n ander onderwerp.
So, ek sal nie tot enige gevolgtrekkings kom nadat daar gerugte is dat Facebook Btrfs op sy bedieners ontplooi het nie. Boonop sal ek aanbeveel om die adresse van daardie bedieners versigtig geheim te hou om die bogenoemde redes.
Waarom is daar die afgelope tyd soveel moeite gedoen om die XFS-kode skoon te maak? Dit is immers aanvanklik 'n derdeparty-lêerstelsel, en ext4 is vir 'n lang tyd stabiel en het kontinuïteit van vorige ewe stabiele weergawes. Watter belangstelling het Red Hat in XFS? Maak dit sin om aktief twee lêerstelsels te ontwikkel wat soortgelyk is in doel - ext4 en XFS?
Ek kan nie onthou wat dit gemotiveer het nie. Dit is heel moontlik dat die inisiatief van Red Hat-kliënte gekom het. Ek onthou dat hierdie soort navorsing gedoen is: op sommige lêerstelsels van stroomop af is 'n reusagtige aantal voorwerpe op hoë-end-aandrywers van die nuwe generasie geskep. Volgens die resultate het XFS beter gedra as ext4. Hulle het dit dus as die mees belowende begin bevorder. Ek sal in elk geval niks sensasioneel hier soek nie.
Vir my is dit asof hulle 'n els met seep vervang het. Daar is geen sin om ext4 en XFS te ontwikkel nie. Beide in parallel en enige van hulle om van te kies. Niks goeds sal hiervan kom nie. Alhoewel daar in die natuur dikwels situasies is wanneer daar baie potensiaal vir groei is, maar daar is geen ruimte om te groei nie. In hierdie geval ontstaan verskeie bisarre lelike nuwe groeisels, waarna almal die vinger wys ("O, kyk, wat sal jy nie in hierdie lewe sien nie!").
Dink jy die kwessie van laagskending is opgelos (in 'n negatiewe sin) met die koms van enkripsiefunksies in ext4, F2FS (om nie te praat van RAID in Btrfs nie)?
Oor die algemeen is die bekendstelling van enige vlakke en die neem van 'n besluit oor die nie-skending daarvan gewoonlik 'n kwessie van beleid, en ek onderneem nie om hier kommentaar oor enigiets te lewer nie. Die objektiewe aspekte van laagskending is van min belang vir enigiemand, maar ons kan sommige daarvan oorweeg deur die voorbeeld van oortreding "van bo" te gebruik, naamlik die implementering in die FS van funksionaliteit wat reeds op die bloklaag bestaan. So 'n "oortreding" is geregverdig met slegs seldsame uitsonderings. Vir elke so 'n geval moet jy eers twee dinge bewys: dat dit werklik nodig is, en dat die ontwerp van die stelsel nie daardeur benadeel sal word nie.
Byvoorbeeld, spieëlspieëling, wat tradisioneel 'n aktiwiteit vir die bloklaag was, maak sin om op die lêerstelselvlak te implementeer. Om verskillende redes. Byvoorbeeld, "stil" data korrupsie (bit rot) vind plaas op skyfaandrywers. Dit is wanneer die toestel behoorlik werk, maar die blokdata word onverwags beskadig onder die invloed van 'n harde gamma-kwantum wat deur 'n verre kwasar uitgestraal word, ens. Die ergste is as hierdie blok 'n FS-stelselblok (superblok, bitmapblok, stoorboomnodus, ens.) blyk te wees, want dit sal beslis tot 'n kernpaniek lei.
Neem asseblief kennis dat die spieëls wat deur die bloklaag (sogenaamde RAID 1) aangebied word, jou nie van hierdie probleem sal red nie. Wel, regtig: iemand moet die kontrolesomme nagaan en die replika lees in geval van mislukking? Daarbenewens maak dit sin om nie net alles te weerspieël nie, maar slegs die metadata. Sommige belangrike data (byvoorbeeld uitvoerbare lêers van kritieke toepassings) kan as metadata gestoor word. In hierdie geval ontvang hulle dieselfde waarborge van veiligheid. Dit maak sin om die beskerming van die oorblywende data aan ander substelsels toe te vertrou (miskien selfs gebruikerstoepassings) - ons het al die nodige voorwaardes hiervoor verskaf.
Sulke "ekonomiese" spieëls het 'n bestaansreg, en hulle kan slegs effektief op die lêerstelselvlak georganiseer word. Andersins is die oortreding van gelaagdheid besig om die substelsel met duplikaatkode deurmekaar te maak ter wille van sommige mikroskopiese voordele. 'n Treffende voorbeeld hiervan is die implementering van RAID-5 met behulp van FS. Sulke oplossings (eie RAID / LVM in die lêerstelsel) maak laasgenoemde in argitektoniese terme dood. Daar moet ook hier op gelet word dat die skending van gelaagdheid deur verskeie soorte bemarkingsswendelaars "aan die gang gesit word". In die afwesigheid van enige idees, word funksionaliteit wat lank reeds op naburige vlakke geïmplementeer is, by die substelsels gevoeg, dit word aangebied as 'n nuwe uiters nuttige kenmerk en word aktief aangedryf.
Reiser4 is daarvan beskuldig dat hy die vlakke “van onder af” oortree het. Op grond van die feit dat die lêerstelsel nie monolities is nie, soos al die ander, maar modulêr, is 'n ongestaafde aanname gemaak dat dit doen wat die vlak hierbo (VFS) behoort te doen.
Is dit moontlik om te praat oor die dood van ReiserFS v3.6 en, byvoorbeeld, JFS? Die afgelope tyd het hulle amper geen aandag in die kern gekry nie. Is hulle verouderd?
Hier moet ons definieer wat die dood van 'n sagtewareproduk beteken. Aan die een kant word hulle suksesvol gebruik (dit is tog waarvoor hulle geskep is), wat beteken dat hulle leef. Aan die ander kant kan ek nie vir JFS praat nie (ek weet nie veel nie), maar ReiserFS (v3) is baie moeilik om by nuwe neigings aan te pas (in die praktyk getoets). Dit beteken dat ontwikkelaars in die toekoms nie aandag daaraan sal gee nie, maar aan diegene wat makliker is om aan te pas. Van hierdie kant af blyk dit, helaas, dit is dood in argitektoniese terme. Ek sal glad nie die konsep van “moreel uitgedien” manipuleer nie. Dit geld byvoorbeeld goed vir 'n klerekas, maar nie op sagtewareprodukte nie. Daar is 'n konsep van minderwaardigheid en meerderwaardigheid in iets. Ek kan absoluut sê dat ReserFS v3 nou in alles minderwaardig is as Reiser4, maar in sommige tipes werklading is dit beter as alle ander stroomop FS'e.
Weet jy van die ontwikkeling van FS Tux3 en HAMMER/HAMMER2 (FS vir DragonFly BSD)?
Ja, ons weet. In Tux3 was ek eens geïnteresseerd in die tegnologie van hul kiekies (die sogenaamde "weergawewysers"), maar in Reiser4 sal ons heel waarskynlik 'n ander roete gaan. Ek het lank daaraan gedink om kiekies te ondersteun en het nog nie besluit hoe om dit vir eenvoudige Reiser4-volumes te implementeer nie. Die feit is dat die nuwerwetse "lui" verwysingstoonbanktegniek wat deur Ohad Rodeh voorgestel word, net vir B-bome werk. Ons het hulle nie. Vir daardie datastrukture wat in Reiesr4 gebruik word, word “lui” tellers nie gedefinieer nie - om dit bekend te stel, is dit nodig om sekere algoritmiese probleme op te los, wat niemand nog aangepak het nie.
Volgens HAMMER: Ek het 'n artikel van die skepper gelees. Stel nie belang nie. Weereens, B-bome. Hierdie datastruktuur is hopeloos verouderd. Ons het dit in die vorige eeu laat vaar.
Hoe beoordeel jy die groeiende vraag na netwerkgroep-FS'e soos CephFS/GlusterFS/ens? Beteken hierdie eis 'n verskuiwing in die prioriteite van ontwikkelaars na netwerk-FS en onvoldoende aandag aan plaaslike FS?
Ja, so 'n verskuiwing in prioriteite het plaasgevind. Die ontwikkeling van plaaslike lêerstelsels het gestagneer. Helaas, om iets betekenisvols vir plaaslike volumes te doen, is nou nogal moeilik en nie almal kan dit doen nie. Niemand wil in hul ontwikkeling belê nie. Dit is omtrent dieselfde as om 'n kommersiële organisasie te vra om geld vir wiskundige navorsing toe te wys – sonder enige entoesiasme sal hulle jou vra hoe jy geld kan maak op 'n nuwe stelling. Nou is 'n plaaslike FS iets wat magies "buite die boks" verskyn en "behoort altyd te werk," en as dit nie werk nie, veroorsaak dit ongeadresseerde gemor soos: "Ja, wat dink hulle!"
Vandaar die gebrek aan aandag aan plaaslike FS, hoewel daar nog baie werk in daardie area is. En ja, almal het hulle tot verspreide berging gewend, wat gebou is op die basis van reeds bestaande plaaslike lêerstelsels. Dis nou baie modieus. Die frase "Big Data" veroorsaak 'n adrenalienstormloop vir baie, wat dit met konferensies, werkswinkels, groot salarisse, ens.
Hoe redelik is dit in beginsel om die netwerklêerstelsel in kernspasie eerder as in gebruikersruimte te implementeer?
’n Baie redelike benadering wat nog nêrens geïmplementeer is nie. Oor die algemeen is die vraag in watter ruimte 'n netwerklêerstelsel geïmplementeer moet word 'n "tweesnydende swaard." Wel, kom ons kyk na 'n voorbeeld. Die kliënt het data op 'n afgeleë masjien aangeteken. Hulle het in die vorm van vuil bladsye in haar bladsykas geval. Dit is die werk vir 'n "dun poort"-netwerklêerstelsel in kernspasie. Dan sal die bedryfstelsel jou vroeër of later vra om daardie bladsye op skyf te skryf om hulle vry te maak. Dan kom die IO-aanstuur (stuur) netwerk FS module ter sprake. Dit bepaal na watter bedienermasjien (bedienernodus) hierdie bladsye sal gaan.
Dan neem die netwerkstapel oor (en, soos ons weet, word dit in kernspasie geïmplementeer). Vervolgens ontvang die bedienernodus daardie pakkie met data of metadata en gee die backend-bergingsmodule opdrag (d.w.s. die plaaslike FS wat in kernspasie werk) om al hierdie goed op te teken. Dus, ons het die vraag verminder tot waar die "stuur" en "ontvang" modules moet werk. As enige van daardie modules in gebruikersruimte loop, sal dit onvermydelik lei tot kontekswisseling (as gevolg van die behoefte om kerndienste te gebruik). Die aantal sulke skakelaars hang af van die implementeringsbesonderhede.
As daar baie sulke skakelaars is, sal berging deurset (I/O werkverrigting) afneem. As jou backend-berging uit stadige skywe bestaan, sal jy nie 'n beduidende daling opmerk nie. Maar as jy vinnige skywe het (SSD, NVRAM, ens.), dan word kontekswisseling reeds 'n "bottelnek" en, deur te bespaar op kontekswisseling, kan werkverrigting aansienlik verhoog word. Die standaard manier om geld te spaar is om modules na kernspasie te skuif. Ons het byvoorbeeld gevind dat die skuif van die 9p-bediener van QEMU na die kern op die gasheermasjien lei tot 'n drievoudige toename in VirtFS-prestasie.
Dit is natuurlik nie 'n netwerk FS nie, maar dit weerspieël die essensie van dinge ten volle. Die nadeel van hierdie optimalisering is oordraagbaarheidskwessies. Vir sommige kan laasgenoemde krities wees. GlusterFS het byvoorbeeld glad geen modules in die kern nie. Danksy dit werk dit nou op baie platforms, insluitend NetBSD.
Watter konsepte kan plaaslike FS'e van netwerke leen en omgekeerd?
Deesdae het netwerk-FS'e as 'n reël byvoegings bo plaaslike FS'e, so ek verstaan nie mooi hoe jy iets van laasgenoemde kan leen nie. Wel, inderdaad, kom ons kyk na 'n maatskappy van 4 werknemers, waarin almal hul eie ding doen: een versprei, 'n ander stuur, die derde ontvang, die vierde winkels. En die vraag, wat kan die maatskappy leen by sy werknemer wat dit stoor, klink op die een of ander manier verkeerd (hy het al lankal wat hy by hom kon leen).
Maar plaaslike FS'e het baie om van netwerke te leer. Eerstens moet jy by hulle leer hoe om logiese volumes op 'n hoë vlak te versamel. Nou die sg “gevorderde” plaaslike lêerstelsels versamel logiese volumes wat uitsluitlik gebruik maak van “virtuele toestel”-tegnologie wat van LVM geleen is (dieselfde aansteeklike lae-oortreding wat die eerste keer in ZFS geïmplementeer is). Met ander woorde, vertaling van virtuele adresse (bloknommers) na regte en terug vind plaas op 'n lae vlak (d.w.s. nadat die lêerstelsel 'n I/O-versoek uitgereik het).
Neem asseblief kennis dat die byvoeging en verwydering van toestelle by logiese volumes (nie spieëls nie) wat op die bloklaag gerangskik is, lei tot probleme waaroor verskaffers van sulke "kenmerke" beskeie swyg. Ek praat van fragmentasie op regte toestelle, wat monsteragtige waardes kan bereik, terwyl alles op 'n virtuele toestel reg is. Min mense stel egter belang in virtuele toestelle: almal stel belang in wat op jou regte toestelle gebeur. Maar ZFS-agtige FS (sowel as enige FS in samewerking met LVM) werk slegs met virtuele skyftoestelle (ken virtuele skyfadresse toe uit gratises, defragmenteer hierdie virtuele toestelle, ens.). En hulle het geen idee wat op regte toestelle gebeur nie!
Stel jou nou voor dat jy geen fragmentasie op die virtuele toestel het nie (dit wil sê, jy het net een groot mate wat daar woon), jy voeg 'n skyf by jou logiese volume, en verwyder dan nog 'n ewekansige skyf van jou logiese volume en herbalanseer dan. En soveel keer. Dit is nie moeilik om jou voor te stel dat jy op die virtuele toestel nog in dieselfde mate lewe, maar op regte toestelle sal jy niks goeds sien nie.
Die ergste is dat jy nie eers in staat is om hierdie situasie reg te stel nie! Die enigste ding wat u hier kan doen, is om die lêerstelsel te vra om die virtuele toestel te defragmenteer. Maar sy sal jou vertel dat alles wonderlik daar is - daar is net een mate, fragmentasie is nul, en dit kan nie beter nie! Dus, logiese volumes wat op die blokvlak gerangskik is, is nie bedoel vir herhaalde byvoeging/verwydering van toestelle nie. Op 'n goeie manier hoef jy net een keer 'n logiese volume op blokvlak bymekaar te maak, dit aan die lêerstelsel te gee en dan niks anders daarmee te doen nie.
Daarbenewens laat die kombinasie van onafhanklike FS+LVM-substelsels nie die inagneming van die verskillende aard van die aandrywers toe waaruit logiese volumes saamgevoeg word nie. Gestel jy het inderdaad 'n logiese volume saamgestel uit HDD en vaste toestand-toestelle. Maar dan sal eersgenoemde defragmentasie vereis, en laasgenoemde nie. Vir laasgenoemde moet jy weggooiversoeke uitreik, maar vir eersgenoemde nie, ens. In hierdie kombinasie is dit egter redelik moeilik om sulke selektiwiteit te demonstreer.
Let daarop dat nadat u u eie LVM op die lêerstelsel geskep het, die situasie nie veel beter word nie. Verder, deur dit te doen, maak jy eintlik 'n einde aan die vooruitsig om dit ooit in die toekoms te verbeter. Dit is baie erg. Verskillende tipes aandrywers kan op dieselfde masjien leef. En as die lêerstelsel nie tussen hulle onderskei nie, wie sal dan?
Nog 'n probleem lê en wag vir die sg. "Write-Anywhere" lêerstelsels (dit sluit ook Reiser4 in, as jy die toepaslike transaksionele model tydens montering gespesifiseer het). Sulke lêerstelsels moet defragmentasie-instrumente verskaf wat ongekend in hul vermoë is. En die laevlak-volumebestuurder help nie hier nie, maar staan net in die pad. Die feit is dat met so 'n bestuurder, jou FS 'n kaart van gratis blokke van slegs een toestel sal stoor - 'n virtuele een. Gevolglik kan u slegs 'n virtuele toestel defragmenteer. Dit beteken dat jou defragmenteerder vir 'n lang, lang tyd op 'n groot enkele spasie virtuele adresse sal werk.
En as jy baie gebruikers het wat ewekansige oorskryf, dan sal die nuttige effek van so 'n defragmenteerder tot nul verminder word. Jou stelsel sal onvermydelik begin stadiger word, en jy sal net jou hande moet vou voor die teleurstellende diagnose "gebroke ontwerp". Verskeie defragmenteerders wat op dieselfde adresspasie loop, sal net met mekaar inmeng. Dit is heeltemal 'n ander saak as jy jou eie kaart van gratis blokke vir elke regte toestel onderhou. Dit sal die defragmentasieproses effektief paralleliseer.
Maar dit kan slegs gedoen word as jy 'n hoëvlak logiese volumebestuurder het. Plaaslike lêerstelsels met sulke bestuurders het nie voorheen bestaan nie (ten minste, ek weet nie van hulle nie). Slegs netwerklêerstelsels (byvoorbeeld GlusterFS) het sulke bestuurders gehad. Nog 'n baie belangrike voorbeeld is die volume integrity check (fsck) nut. As jy jou eie onafhanklike kaart van gratis blokke vir elke subvolume stoor, kan die prosedure vir die kontrolering van 'n logiese volume effektief geparalleliseer word. Met ander woorde, logiese volumes met hoëvlakbestuurders skaal beter.
Boonop sal u met laevlakvolumebestuurders nie volwaardige kiekies kan organiseer nie. Met LVM- en ZFS-agtige lêerstelsels kan jy slegs plaaslike foto's neem, maar nie globale foto's nie. Plaaslike foto's laat jou toe om net gewone lêerbewerkings onmiddellik terug te draai. En niemand daar sal bedrywighede met logiese volumes (toevoeging/verwydering van toestelle) terugrol nie. Kom ons kyk hierna met 'n voorbeeld. Op 'n sekere tydstip, wanneer jy 'n logiese volume van twee toestelle A en B het wat 100 lêers bevat, neem jy 'n momentopname van die stelsel S en skep dan nog honderd lêers.
Daarna voeg jy toestel C by jou volume, en rol uiteindelik jou stelsel terug na momentopname S. Vraag: Hoeveel lêers en toestelle bevat jou logiese volume na terugrol na S? Daar sal 100 lêers wees, soos jy dalk geraai het, maar daar sal 3 toestelle wees - dit is dieselfde toestelle A, B en C, hoewel daar net twee toestelle in die stelsel was op die tydstip waarop die momentopname geskep is (A en B) ). Die voeg toestel C-bewerking het nie teruggedraai nie, en as jy nou toestel C van die rekenaar verwyder, sal dit jou data korrupteer, dus voordat jy uitvee sal jy eers 'n duur bewerking moet uitvoer om die toestel van die herbalanseer logiese volume te verwyder, wat sal al die data van toestel C na toestelle A en B verstrooi. Maar as jou FS globale momentopnames ondersteun, sal sulke herbalansering nie nodig wees nie, en na 'n onmiddellike terugrol na S, kan jy toestel C veilig van die rekenaar verwyder.
So, globale kiekies is goed omdat dit jou toelaat om die duur verwydering (byvoeging) van 'n toestel van 'n logiese volume (na 'n logiese volume) met 'n groot hoeveelheid data te vermy (natuurlik, as jy onthou om jou stelsel te "snapshot" op die regte tyd). Laat ek u daaraan herinner dat die skep van foto's en die terugrol van die lêerstelsel na hulle onmiddellike bewerkings is. Die vraag kan ontstaan: hoe is dit selfs moontlik om 'n operasie onmiddellik terug te rol op 'n logiese volume wat jou drie dae geneem het? Maar dit is moontlik! Met dien verstande dat jou lêerstelsel korrek ontwerp is. Ek het drie jaar gelede met die idee van sulke "3D-kiekies" vorendag gekom, en verlede jaar het ek hierdie tegniek gepatenteer.
Die volgende ding wat plaaslike FS'e van netwerke moet leer, is om metadata op aparte toestelle te stoor op dieselfde manier as wat netwerk FS'e dit op aparte masjiene stoor (die sogenaamde metadatabedieners). Daar is toepassings wat hoofsaaklik met metadata werk, en hierdie toepassings kan baie versnel word deur die metadata op duur hoëprestasie-bergingstoestelle te plaas. Met die FS+LVM-kombinasie sal jy nie sulke selektiwiteit kan demonstreer nie: LVM weet nie wat op die blok is wat jy daarheen deurgegee het nie (data daar of metadata).
Jy sal nie veel voordeel trek uit die implementering van jou eie lae-vlak LVM in die FS in vergelyking met die FS+LVM kombinasie nie, maar wat jy baie goed kan doen, is om die FS deurmekaar te maak sodat dit later onmoontlik word om met sy kode te werk. ZFS en Btrfs, wat met virtuele toestelle gejaag het, is almal duidelike voorbeelde van hoe lae-oortreding die stelsel in argitektoniese terme doodmaak. So, hoekom is ek dit alles? Boonop hoef u nie u eie laevlak LVM in die lêerstelsel te installeer nie. In plaas daarvan moet u toestelle op 'n hoë vlak in logiese volumes saamvoeg, soos sommige netwerklêerstelsels met verskillende masjiene (bergingsnodes) doen. Dit is waar, hulle doen dit walglik as gevolg van die gebruik van slegte algoritmes.
Voorbeelde van absoluut verskriklike algoritmes is die DHT-vertaler in die GlusterFS-lêerstelsel en die sogenaamde CRUSH-kaart in die Ceph-lêerstelsel. Nie een van die algoritmes wat ek gesien het, het my bevredig in terme van eenvoud en goeie skaalbaarheid nie. Ek moes dus algebra onthou en alles self uitdink. In 2015, terwyl ek met bundels oor hash-funksies geëksperimenteer het, het ek iets uitgedink en gepatenteer wat my pas. Nou kan ek sê dat die poging om dit alles in die praktyk te bring, suksesvol was. Ek sien geen probleme met skaalbaarheid in die nuwe benadering nie.
Ja, elke subvolume sal 'n aparte struktuur benodig soos 'n superblok in geheue. Is dit baie skrikwekkend? Oor die algemeen weet ek nie wie gaan "die see kook" en logiese volumes van honderdduisende of meer toestelle op een plaaslike masjien skep nie. As iemand dit vir my kan verduidelik, sal ek baie dankbaar wees. Intussen is dit vir my bemarkingsbull.
Hoe het veranderinge in die kernbloktoestelsubstelsel (byvoorbeeld die voorkoms van blk-mq) die vereistes vir FS-implementering beïnvloed?
Hulle het geen impak gehad nie. Ek weet nie wat op die bloklaag sou gebeur wat dit nodig sou maak om 'n nuwe FS te ontwerp nie. Die interaksie-koppelvlak van hierdie subsisteme is baie swak. Van die bestuurderskant af moet die FS net geraak word deur die voorkoms van nuwe soorte dryf, waarna die bloklaag eers aangepas sal word, en dan die FS (vir reiser4 beteken dit die verskyning van nuwe inproppe).
Beteken die opkoms van nuwe soorte media (byvoorbeeld SMR, of die alomteenwoordigheid van SSD's) fundamenteel nuwe uitdagings vir lêerstelselontwerp?
Ja. En dit is normale aansporings vir die ontwikkeling van FS. Uitdagings kan anders en heeltemal onverwags wees. Ek het byvoorbeeld gehoor van aandrywers waar die spoed van 'n I/O-operasie hoogs afhanklik is van die grootte van 'n stuk data en die afwyking daarvan. In Linux, waar die grootte van die FS-blok nie die bladsygrootte kan oorskry nie, sal so 'n skyf nie sy volle vermoëns by verstek wys nie. As jou lêerstelsel egter korrek ontwerp is, is daar 'n kans om baie meer daaruit te kry.
Hoeveel mense werk tans met die Reiser4-kode behalwe jy?
Minder as wat ek sou wou hê, maar ek ervaar ook nie 'n akute tekort aan hulpbronne nie. Ek is meer as tevrede met die tempo van ontwikkeling van Reiser4. Ek gaan nie "perde ry" nie - dit is nie die regte area nie. Hier, "as jy rustiger ry, sal jy aanhou!" 'n Moderne lêerstelsel is die mees komplekse kernsubstelsel, waarvan die verkeerde ontwerpbesluite daaropvolgende jare se menslike werk kan ongedaan maak.
Deur vrywilligers aan te bied om iets te implementeer, waarborg ek altyd dat die pogings beslis tot die korrekte resultaat sal lei, wat in aanvraag vir ernstige behoeftes kan wees. Soos u verstaan, kan daar nie baie sulke waarborge gelyktydig wees nie. Terselfdertyd kan ek nie "figure" verdra wat onbeskaamd "kenmerke" van ooglopend onbruikbare sagteware bevorder, honderde gebruikers en ontwikkelaars mislei, en terselfdertyd sit en glimlag op kernberaad.
Het enige maatskappy bereidwilligheid uitgespreek om die ontwikkeling van Reiser4 te ondersteun?
Ja, daar was sulke voorstelle, inkl. en van 'n groot verkoper. Maar hiervoor moes ek na 'n ander land trek. Ongelukkig is ek nie meer 30 jaar oud nie, ek kan nie met die eerste fluitjie so wegbreek en weggaan nie.
Watter kenmerke ontbreek tans van Reiser4?
Daar is geen "verander grootte"-funksie vir eenvoudige volumes, soortgelyk aan dié wat in ReiserFS(v3) gevind word. Boonop sal lêerbewerkings met die DIRECT_IO-vlag nie skade doen nie. Vervolgens wil ek graag 'n volume in "semantiese subvolumes" kan skei, wat nie 'n vaste grootte het nie, en wat as onafhanklike volumes gemonteer kan word. Hierdie probleme is goed vir beginners wat hul hand aan die "regte ding" wil probeer.
En laastens, ek wil graag netwerk logiese volumes hê met eenvoudige implementering en administrasie (moderne algoritmes laat dit reeds toe). Maar wat Reiser4 beslis nooit sal hê nie, is RAID-Z, scrubs, vrye ruimte-kas, 128-bis veranderlikes en ander bemarkings-snert wat ontstaan het teen die agtergrond van 'n tekort aan idees onder die ontwikkelaars van sommige lêerstelsels.
Kan alles wat nodig mag wees deur inproppe geïmplementeer word?
As ons net praat in terme van koppelvlakke en plugins (modules) wat hulle implementeer, dan nie alles nie. Maar as jy ook verhoudings op hierdie koppelvlakke bekendstel, dan sal jy onder andere die konsepte van hoër polimorfismes hê, waarmee jy reeds klaar kan kom. Stel jou voor dat jy hipoteties 'n objekgeoriënteerde looptydstelsel gevries het, die waarde van die instruksiewyser verander het om na 'n ander inprop te wys wat dieselfde X-koppelvlak implementeer, en dan die stelsel ontvries sodat dit voortgaan om uit te voer.
As die eindgebruiker nie so 'n "vervanging" opmerk nie, dan sê ons dat die stelsel nul-orde polimorfisme in die X-koppelvlak het (of die stelsel is heterogeen in die X-koppelvlak, wat dieselfde is). As jy nou nie net 'n stel koppelvlakke het nie, maar ook verwantskappe daarop het (koppelvlakgrafiek), dan kan jy polimorfismes van hoër ordes bekendstel, wat die heterogeniteit van die stelsel reeds in die "buurt" van enige koppelvlak sal kenmerk. Ek het lank gelede so 'n klassifikasie ingestel, maar dit het ongelukkig nooit gebeur nie.
Dus, met die hulp van inproppe en sulke hoër polimorfismes, kan u enige bekende kenmerk beskryf, sowel as diegene wat nog nooit genoem is nie, "voorspel". Ek kon dit nie streng bewys nie, maar ek weet ook nog nie van 'n teenvoorbeeld nie. Oor die algemeen het hierdie vraag my laat dink aan Felix Klein se "Erlangen Program". Op 'n tyd het hy probeer om alle meetkunde as 'n vertakking van algebra (spesifiek groepteorie) voor te stel.
Nou tot die hoofvraag - hoe gaan dit met die bevordering van Reiser4 tot die hoofkern? Was daar enige publikasies oor die argitektuur van hierdie lêerstelsel waaroor jy in die laaste onderhoud gepraat het? Hoe relevant is hierdie vraag vanuit jou oogpunt?
Oor die algemeen vra ons al vir drie jaar vir insluiting in die hooftak. Reiser se laaste opmerking in die openbare draad waar die trekversoek gemaak is, het onbeantwoord gebly. So alle verdere vrae is nie vir ons nie. Ek verstaan persoonlik nie hoekom ons in 'n spesifieke bedryfstelsel moet "saamsmelt" nie. Op Linux het die lig nie soos 'n wig saamgevloei nie. Dus, daar is 'n aparte bewaarplek waarin daar verskeie takpoorte vir verskillende bedryfstelsels sal wees. Wie dit nodig het, kan die ooreenstemmende poort kloon en doen wat jy wil daarmee (natuurlik binne die lisensie). Wel, as iemand dit nie nodig het nie, dan is dit nie my probleem nie. Op hierdie punt stel ek voor om die kwessie van "bevordering in die hoof Linux-kern" as afgehandel te oorweeg.
Publikasies oor FS-argitektuur is relevant, maar tot dusver het ek net tyd gekry vir my nuwe resultate, wat ek as 'n hoër prioriteit beskou. Nog iets is dat ek 'n wiskundige is, en in wiskunde is enige publikasie 'n opsomming van stellings en hul bewyse. Om enigiets daar te publiseer sonder bewyse is 'n teken van slegte smaak. As ek enige stelling oor die argitektuur van die FS deeglik bewys of weerlê, dan sal die gevolg sulke hope wees dat dit nogal moeilik sal wees om deur te kom. Wie het dit nodig? Dit is waarskynlik hoekom alles in sy ou vorm bly – die bronkode en kommentaar daarop.
Wat is die afgelope paar jaar nuut in Reiser4?
Die langverwagte stabiliteit het uiteindelik gerealiseer. Een van die laastes wat verskyn het, was 'n fout wat gelei het tot "onuitveebare" gidse. Die moeilikheid was dat dit net teen die agtergrond van naamhash-botsings verskyn het en met 'n sekere ligging van gidsrekords in 'n boomnodus. Ek kan egter steeds nie Reiser4 vir produksie aanbeveel nie: hiervoor moet jy werk doen met aktiewe interaksie met produksiestelseladministrateurs.
Ons het uiteindelik daarin geslaag om ons jarelange idee – verskillende transaksiemodelle – te implementeer. Voorheen het Reiser4 net een hardgekodeerde Macdonald-Reiser-model gebruik. Dit het ontwerpprobleme veroorsaak. In die besonder is momentopnames nie moontlik in so 'n transaksionele model nie - dit sal beskadig word deur 'n atoomkomponent genaamd "OORSKRYF SET". Reiser4 ondersteun tans drie transaksiemodelle. In een van hulle (Write-Anywhere) bevat die atoomkomponent OORSKRYF SET slegs stelselbladsye (beelde van skyfbitmaps, ens.), wat nie “gefotografeer” kan word nie (die hoender-en-eierprobleem).
Die prentjies kan dus nou op die beste moontlike manier gerealiseer word. In 'n ander transaksionele model gaan alle gewysigde bladsye slegs na die OORSKRYF-STEL (dit wil sê, dit is in wese suiwer joernale). Hierdie model is vir diegene wat gekla het oor die vinnige fragmentering van Reiser4-partisies. Nou in hierdie model sal jou partisie nie vinniger fragmenteer as met ReiserFS (v3). Al drie bestaande modelle, met 'n paar voorbehoude, waarborg die atomiteit van bedrywighede, maar modelle met verlies aan atomiteit en die behoud van slegs die integriteit van die afdeling kan ook nuttig wees. Sulke modelle kan nuttig wees vir alle soorte toepassings (databasisse, ens.), wat reeds sommige van hierdie funksies oorgeneem het. Dit is baie maklik om hierdie modelle by Reiser4 te voeg, maar ek het dit nie gedoen nie, want niemand het my gevra nie, en ek het dit persoonlik nie nodig nie.
Metadata-kontrolesomme het verskyn en ek het dit onlangs aangevul met “ekonomiese” spieëls” (steeds onstabiele materiaal). As die kontrolesom van enige blok misluk, lees Reiser4 onmiddellik die ooreenstemmende blok vanaf die replika-toestel. Let daarop dat ZFS en Btrfs dit nie kan doen nie: die ontwerp laat dit nie toe nie. Daar moet jy 'n spesiale agtergrondskanderingproses genaamd "skrop" uitvoer en wag totdat dit by die problematiese blok kom. Programmeerders noem sulke gebeurtenisse figuurlik "krukke".
En laastens het heterogene logiese volumes verskyn wat alles bied wat ZFS, Btrfs, bloklaag, sowel as FS+LVM kombinasies in beginsel nie kan verskaf nie - parallelle skalering, O(1) skyfadrestoewyser, deursigtige datamigrasie tussen subvolumes. Laasgenoemde het ook 'n gebruikerskoppelvlak. Nou kan jy maklik die warmste data na die hoogste-prestasie-aandrywer op jou volume skuif.
Boonop is dit moontlik om enige vuil bladsye dringend na so 'n skyf te spoel, en sodoende toepassings wat dikwels fsync(2) noem aansienlik bespoedig. Ek let daarop dat die bloklaag-funksionaliteit, genaamd bcache, glad nie sulke vryheid van optrede bied nie. Nuwe logiese volumes is gebaseer op my algoritmes (daar is ooreenstemmende patente). Die sagteware is reeds redelik stabiel, dit is heel moontlik om dit te probeer, prestasie te meet, ens. Die enigste ongerief is dat jy vir eers die volume-konfigurasie handmatig moet opdateer en iewers stoor.
Tot dusver kon ek my idees met 10 persent implementeer.Ek het egter daarin geslaag in wat ek as die moeilikste beskou het - om logiese volumes te verbind met 'n flitsprosedure wat alle uitgestelde aksies in reiser4 uitvoer. Dit is alles nog in die eksperimentele "format41"-tak.
Slaag Reiser4 xfstoetse?
Dit het ten minste vir my gedoen toe ek die laaste vrystelling voorberei het.
Is dit in beginsel moontlik om Reiser4 'n netwerk (cluster) FS te maak deur inproppe te gebruik?
Dit is moontlik, en selfs nodig! As jy 'n netwerklêer skep wat gebaseer is op 'n behoorlik ontwerpte plaaslike lêerstelsel, sal die resultaat baie indrukwekkend wees! In moderne netwerk-FS'e is ek nie tevrede met die teenwoordigheid van 'n backend-bergingvlak, wat met enige plaaslike FS geïmplementeer word nie. Die bestaan van hierdie vlak is heeltemal ongeregverdig. Die netwerk FS moet direk met die bloklaag interaksie hê, en nie die plaaslike FS vra om enige ander dienslêers te skep nie!
Oor die algemeen is die verdeling van lêerstelsels in plaaslike en netwerk van die bose een. Dit het ontstaan uit die onvolmaaktheid van die algoritmes wat dertig jaar gelede gebruik is, en in die plek daarvan is nog niks voorgestel nie. Dit is ook die rede vir die verskyning van 'n massa onnodige sagtewarekomponente (verskeie dienste, ens.). Op 'n goeie manier moet daar net een FS in die vorm van 'n kernmodule en 'n stel gebruikershulpmiddels op elke masjien geïnstalleer wees - 'n groepknoop. Hierdie FS is beide plaaslik en netwerk. En niks meer nie!
As niks uitwerk met Reiser4 op Linux nie, wil ek graag 'n FS vir FreeBSD aanbied (aanhaling uit 'n vorige onderhoud: “...FreeBSD... has academic roots... And this means that with a high degree of probability we sal 'n gemeenskaplike taal met die ontwikkelaars vind”) ?
So, soos ons pas uitgevind het, het alles reeds perfek uitgewerk met Linux: daar is 'n aparte werkende Reiser4-poort daarvoor in die vorm van 'n meestertak van ons bewaarplek. Ek het nie van FreeBSD vergeet nie! Bied aan! Ek is gereed om nou saam te werk met diegene wat die binnekant van FreeBSD goed ken. Terloops: wat ek baie van hul gemeenskap hou, is dat besluite daar geneem word deur 'n bygewerkte raad van onafhanklike kundiges, wat niks te doen het met die regeringsbedrog van een permanente persoon nie.
Hoe beoordeel jy die Linux-gebruikersgemeenskap vandag? Het dit meer "pop" geword?
Gegewe die aard van my werk, is dit nogal moeilik vir my om dit te assesseer. Meestal kom gebruikers na my toe met foutverslae en versoeke om die afdeling reg te stel. Gebruikers as gebruikers. Sommige is meer vaardig, ander minder. Almal word dieselfde behandel. Wel, as die gebruiker my instruksies ignoreer, verskoon my dan: die ignoreerbevel sal ook van my kant af ingevoer word.
Is dit moontlik om die ontwikkeling van lêerstelsels vir die volgende vyf tot tien jaar te voorspel? Wat dink jy is die belangrikste uitdagings wat FS-ontwikkelaars in die gesig staar?
Ja, dit is nie moeilik om so 'n voorspelling te maak nie. Daar was vir 'n lang tyd geen ontwikkeling van lêerstelsels in die stroomop nie. Slegs die voorkoms daarvan word geskep. Ontwikkelaars van plaaslike lêerstelsels het probleme ondervind wat verband hou met swak ontwerp. 'n Waarskuwing moet hier gemaak word. Ek beskou nie die sogenaamde "berging", "lek" en oordrag van kode as ontwikkeling en ontwikkeling nie. En ek klassifiseer nie die misverstand genaamd "Btrfs" as 'n ontwikkeling vir die redes wat ek reeds verduidelik het nie.
Elke pleister maak sy probleme net erger. Wel. en daar is altyd verskillende soorte “evangeliste” vir wie “alles werk”. Basies is dit skoolkinders en studente wat lesings oorslaan. Stel jou net voor: dit werk vir hom, maar die professor nie. Wat 'n adrenalienstormloop is dit tog! Vanuit my oogpunt word die grootste skade veroorsaak deur die "vakmanne" wat gehaas het om die wonderlike kenmerke van Btrfs entoesiasties op allerhande lae soos systemd, docker, ens. - dit lyk reeds soos metastases.
Kom ons probeer nou om 'n voorspelling vir vyf tot tien jaar te maak. Ek het reeds kortliks gelys wat ons in Reiser4 gaan doen. Die grootste uitdaging vir plaaslike FS-ontwikkelaars van stroomop sal wees (ja, dit het reeds geword) die onvermoë om 'n ordentlike werk teen 'n salaris te doen. Sonder enige idees op die gebied van databerging, sal hulle voortgaan om hierdie ongelukkige VFS, XFS en ext4 te probeer regmaak. Die situasie met VFS lyk veral komies teen hierdie agtergrond, wat herinner aan die waansinnige modernisering van 'n restaurant waarin daar geen sjefs is nie, en geen sjefs verwag word nie.
Nou sluit die VFS-kode, sonder enige voorwaardes, verskeie geheuebladsye op dieselfde tyd en nooi die onderliggende FS uit om daarop te werk. Dit is ingestel om Ext4 se werkverrigting op uitveebewerkings te verbeter, maar soos dit maklik is om te verstaan, is sulke gelyktydige sluiting heeltemal onversoenbaar met gevorderde transaksiemodelle. Dit wil sê, jy sal nie net ondersteuning vir een of ander slim lêerstelsel in die kern kan byvoeg nie. Ek weet nie wat die situasie in ander areas van Linux is nie, maar wat lêerstelsels betref, is dit onwaarskynlik dat enige ontwikkeling hier versoenbaar sal wees met die beleid wat Torvalds in die praktyk volg (akademiese projekte word uitgeskop, en swendelaars wat het geen idee wat 'n B-boom, eindelose krediete van trust uitgereik word nie). Daarom is 'n koers ingeslaan vir stadige verval. Natuurlik sal hulle met alle mag probeer om dit as “ontwikkeling” voor te gee.
Verder sal die "bewaarders" van lêerstelsels, wat besef dat jy nie veel uit "berging" alleen sal verdien nie, hul hand aan 'n meer winsgewende besigheid probeer. Dit is as 'n reël verspreide lêerstelsels en virtualisering. Miskien sal hulle die modieuse ZFS êrens anders oordra waar dit nog nie bestaan nie. Maar dit, soos alle FS van die stroomop, lyk soos 'n Nuwejaarsboom: as jy 'n paar ander klein goedjies bo-op kan hang, dan kan jy nie dieper kom nie. Ek gee toe dat dit moontlik is om 'n ernstige ondernemingstelsel te bou wat op ZFS gebaseer is, maar aangesien ons nou die toekoms bespreek, kan ek ongelukkig net sê dat ZFS hopeloos is in hierdie verband: met hul virtuele toestelle het die ouens die suurstof afgesny vir hulself en toekomstige geslagte vir verdere ontwikkeling. ZFS is iets van die verlede. En ext4 en XFS is nie eers eergister nie.
Dit is die moeite werd om afsonderlik te noem oor die sensasionele konsep van "Linux-lêerstelsel van die volgende generasie". Dit is 'n heeltemal politieke en bemarkingsprojek wat geskep is vir die geleentheid, so te sê, om "die toekoms van lêerstelsels" in Linux agter spesifieke karakters vas te pen. Die feit is dat Linux vroeër "net vir die pret" was. Maar nou is dit hoofsaaklik 'n geldmaakmasjien. Hulle is gemaak op alles moontlik. Dit is byvoorbeeld baie moeilik om 'n goeie sagtewareproduk te skep, maar slim "ontwikkelaars" het lankal besef dat dit glad nie nodig is om inspanning te doen nie: jy kan nie-bestaande sagteware suksesvol verkoop wat by alle soorte publiek aangekondig en bevorder is. gebeure - die belangrikste ding is dat die aanbiedingskyfies meer "kenmerke" moet bevat.
Lêerstelsels is perfek hiervoor, want jy kan veilig vir tien jaar op die resultaat beding. Wel, as iemand later kla oor die gebrek aan hierdie einste resultaat, dan verstaan hy eenvoudig niks van lêerstelsels nie! Dit herinner aan 'n finansiële piramide: aan die bopunt is die avonturiers wat hierdie gemors begin het, en daardie paar wat "gelukkig" was: hulle het "dividende onttrek", m.a.w. geld vir ontwikkeling ontvang, goed betaalde pos as bestuurders gekry, by konferensies “opgedaag” ens.
Volgende kom diegene wat "ongelukkig" is: hulle sal verliese tel, die gevolge hanteer van die ontplooiing van 'n onbruikbare sagtewareproduk in produksie, "ens. Daar is baie meer van hulle. Wel, aan die basis van die piramide is daar 'n groot massa ontwikkelaars wat nuttelose kode "saag". Hulle is die grootste verloorders, want verlore tyd kan nie teruggegee word nie. Sulke piramides is uiters voordelig vir Torvalds en sy medewerkers. En hoe meer van hierdie piramides, hoe beter vir hulle. Om sulke piramides te voed, kan enigiets in die kern geneem word. Natuurlik sê hulle in die openbaar die teenoorgestelde. Maar ek oordeel nie deur woorde nie, maar deur dade.
Dus, "die toekoms van lêerstelsels in Linux" is nog 'n hoogs bevorderde, maar skaars bruikbare sagteware. Na Btrfs, met 'n hoë waarskynlikheid, sal die plek van so 'n "toekoms" deur Bcachefs ingeneem word, wat nog 'n poging is om die Linux-bloklaag met 'n lêerstelsel te kruis ('n slegte voorbeeld is aansteeklik). En wat tipies is: daar is dieselfde probleme as in Btrfs. Ek het dit lank vermoed, en toe kon ek op een of ander manier nie weerstaan nie en kyk na die kode - dit is waar!
Die skrywers van Bcachefs en Btrfs het, toe hulle hul FS geskep het, aktief ander mense se bronne gebruik en min daarvan verstaan. Die situasie herinner baie aan die kinderspeletjie “stukkende foon”. En ek kan my min of meer indink hoe hierdie kode by die kern ingesluit sal word. Eintlik sal niemand die "harke" sien nie (almal sal later daarop trap). Na talle kibbels oor die styl van die kode, beskuldigings van nie-bestaande oortredings, ens., sal 'n gevolgtrekking gemaak word oor die "lojaliteit" van die skrywer, hoe goed hy "interaksie" met ander ontwikkelaars, en hoe suksesvol dit alles kan word dan aan korporasies verkoop.
Die eindresultaat sal niemand interesseer nie. Twintig jaar gelede sou ek dalk belang gestel het, maar nou word die vrae anders gestel: sal dit moontlik wees om dit te bevorder sodat sekere mense binne die volgende tien jaar in diens geneem sal word. En, helaas, dit is nie gebruiklik om oor die eindresultaat te wonder nie.
Oor die algemeen sal ek dit ten sterkste aanbeveel om nie u lêerstelsel van nuuts af te begin herontdek nie. Want selfs aansienlike finansiële beleggings sal oor tien jaar nie genoeg wees om iets mededingend te kry nie. Natuurlik praat ek van ernstige projekte, en nie van dié wat bedoel is om in die kern "ingedruk" te word nie. Dus, 'n meer effektiewe manier om jouself uit te druk, is om aan te sluit by werklike ontwikkelings, soos ons. Dit is natuurlik nie maklik om te doen nie – maar dit is die geval met enige hoëvlakprojek.
Eerstens sal u die probleem wat ek sal bied, onafhanklik moet oorkom. Daarna sal ek, oortuig van die erns van jou voornemens, begin help. Tradisioneel gebruik ons net ons eie ontwikkelings. Die uitsonderings is kompressie-algoritmes en sommige hash-funksies. Ons stuur nie ontwikkelaars om na konferensies te reis nie, en dan sit ons nie en kombineer ander mense se idees ("miskien wat sal gebeur"), soos gebruiklik in die meeste opstarters is nie.
Ons ontwikkel alle algoritmes self. Ek stel tans belang in die algebraïese en kombinatoriese aspekte van databergingwetenskap. Veral eindige velde, asimptotiek, bewys van ongelykhede. Daar is ook werk vir gewone programmeerders, maar ek moet jou dadelik waarsku: alle voorstelle om "na 'n ander FS te kyk en dieselfde te doen" word geïgnoreer. Patches wat gemik is op nouer integrasie met Linux via VFS sal ook daarheen gaan.
So, ons het nie 'n hark nie, maar ons het 'n begrip van waarheen ons moet beweeg, en ons het vertroue dat hierdie rigting die regte een is. Hierdie begrip het nie in die vorm van manna uit die hemel gekom nie. Laat ek jou daaraan herinner dat ons 29 jaar se ontwikkelingservaring agter die rug het, twee lêerstelsels wat van nuuts af geskryf is. En dieselfde aantal dataherwinningsprogramme. En dit is baie!
Bron: opennet.ru