Det andet interview med Eduard Shishkin, udvikler af Reiser4-filsystemet, er blevet offentliggjort.
For at begynde skal du minde læserne om, hvor og hvem du arbejder for.
Jeg arbejder som Principal Storage Architect hos Huawei Technologies, German Research Center. I virtualiseringsafdelingen beskæftiger jeg mig med forskellige aspekter af datalagring. Mine aktiviteter er ikke relateret til et bestemt operativsystem.
Forpligter du dig i øjeblikket til hovedkernegrenen?
Meget sjældent, og kun hvis min arbejdsgiver kræver det. Sidste gang var for omkring tre år siden, sendte jeg patches for at øge gennemløbet for lagerplads, der deles på værter ved hjælp af 9p-protokollen (et andet navn for denne virksomhed er VirtFS). En vigtig note skal gøres her: Selvom jeg har arbejdet med Linux i lang tid, har jeg aldrig været fan af det, det vil sige, at jeg "trækker vejret jævnt", som med alt andet. Især hvis jeg bemærker en fejl, kan jeg højst påpege den én gang. Og så man så kan følge nogen og overtale dem – det sker ikke.
Jeg kan huske sidste gang, for ti år siden, du var ret kritisk over for kerneudviklingsstilen. Fra dit (eller måske virksomhedens) synspunkt, har noget ændret sig, er samfundet blevet mere lydhørt eller ej? Hvis ikke, hvem mener du er skylden?
Jeg har aldrig set nogen ændringer til det bedre. Fællesskabets hovedproblem er udskiftningen af videnskab med politiske teknologier, personlige relationer, flertalsopinion, populisme, råd fra "indre stemmer", rådne kompromiser, alt andet end videnskab. Datalogi er, hvad man end må sige, først og fremmest en eksakt videnskab. Og hvis nogen begynder at proklamere deres egen værdi for 2x2, forskellig fra 4, under "Linux way"-flaget eller under et andet flag, så er det usandsynligt, at dette bringer andet end skade.
Alle problemer skyldes primært inkompetence og manglende uddannelse hos dem, der træffer beslutninger. Hvis en leder er inkompetent, er han ikke i stand til at træffe en objektiv, tilstrækkelig beslutning. Hvis han også er ukulturel, er han ikke i stand til at finde en kompetent specialist, der vil give ham det rigtige råd. Med stor sandsynlighed vil valget falde på en svindler, der siger "tilsyneladende korrekte ting." Et korrupt miljø udvikler sig altid omkring inkompetente ensomme ledere. Desuden kender historien ingen undtagelser i denne henseende, og fællesskabet er den klareste bekræftelse på dette.
Hvordan vurderer du fremskridtene i Btrfs udvikling? Slippede denne FS af med børnesygdomme? Hvordan placerer du det for dig selv - som en FS "til hjemmet" eller også til virksomhedsbrug?
Jeg slap ikke af med det. Alt, hvad jeg nævnte for 11 år siden, er stadig relevant i dag. Et af problemerne med Btrfs, der gør det uegnet til seriøse behov, er problemet med ledig plads. Jeg taler ikke engang om, at brugeren bliver bedt om at løbe til butikken efter en ny disk i situationer, hvor enhver anden FS ville vise en masse ledig plads på partitionen. Manglende evne til at gennemføre en operation på et logisk volumen på grund af mangel på ledig plads er heller ikke det værste. Det værste er, at en uprivilegeret bruger næsten altid kan omgå enhver diskkvote, fratage alle ledig plads på ret kort tid.
Det ser sådan ud (testet til Linux-kerne 5.12). Et script lanceres på et nyinstalleret system, som i en løkke opretter filer med bestemte navne i hjemmebiblioteket, skriver data til dem med bestemte forskydninger og derefter sletter disse filer. Efter et minut med at køre dette script, sker der ikke noget usædvanligt. Efter fem minutter øges andelen af optaget plads på skillevæggen en smule. Efter to til tre timer når den 50% (med en startværdi på 15%). Og efter fem eller seks timers arbejde går scriptet ned med fejlen "der er ingen ledig plads på partitionen." Herefter er du ikke længere i stand til at skrive en 4K-fil til din partition.
En interessant situation opstår: du endte med ikke at skrive noget til partitionen, og al den ledige plads (ca. 85%) forsvandt et sted. Analyse af en sektion, der er udsat for et sådant angreb, vil afsløre mange træknuder, der kun indeholder ét element (et objekt udstyret med en nøgle), flere bytes i størrelse. Det vil sige, at indholdet, der tidligere optog 15% af diskpladsen, viste sig at være jævnt "smurt" over hele partitionen, så der ikke er nogen steder at skrive en ny fil, fordi dens nøgle er større end alle eksisterende, og den gratis blokke på partitionen er løbet tør.
Desuden sker alt dette allerede på den grundlæggende Btrfs-konfiguration (uden nogen snapshots, undervolumener osv.), og det er lige meget, hvordan du beslutter dig for at gemme filkroppe i den FS (som "fragmenter" i et træ eller som udstrækninger af uformaterede blokke) - slutresultatet vil være det samme.
Du vil ikke være i stand til at udsætte andre upstream-filsystemer for et sådant angreb (uanset hvad de fortæller dig). Jeg forklarede årsagen til problemet for længe siden: dette er en fuldstændig perversion af B-træ-konceptet i Btrfs, som gør det muligt for det spontant eller bevidst at degenerere. Især under visse belastninger vil dit filsystem kontinuerligt "falde fra hinanden" under drift af sig selv, uden hjælp udefra. Det er klart, at alle slags "pressende" baggrundsprocesser kun vil redde dagen på individuelle desktops.
På kollektive servere vil en angriber altid være i stand til at "komme foran" dem. Systemadministratoren vil ikke engang være i stand til at afgøre, hvem der præcis mobbede ham. Den hurtigste måde at løse dette problem i Btrfs er at genoprette strukturen af et almindeligt B-træ, dvs. redesign af diskformatet og omskrivning af væsentlige dele af Btrfs-koden. Dette vil tage 8-10 år, inklusive debugging, forudsat at udviklerne nøje fulgte de originale artikler om de relevante algoritmer og datastrukturer og ikke spillede spillet "broken phone", som det er sædvanligt (og opmuntret) i "Linux" vej".
Her skal vi også tilføje den tid, der kræves for, at udviklere forstår alt dette. Det er her, det bliver sværere. I hvert fald var 10 år ikke nok for dem at forstå. Nå, indtil da kan du ikke håbe på et mirakel. Det vil ikke ske i form af en monteringsmulighed "som du og jeg ikke vidste om", eller i form af et plaster, der "bare er et spørgsmål om forretning" at forberede. For hver sådan forhastet "fix" vil jeg præsentere et nyt scenarie for degeneration. B-træer er et af mine yndlingsemner, og jeg må sige, at disse strukturer ikke tolererer friheder med sig selv!
Hvordan placerer jeg Btrfs for mig selv? Som noget, der absolut ikke kan kaldes et filsystem, endsige brugt. Fordi FS per definition er et OS-undersystem, der er ansvarlig for den effektive styring af "diskplads"-ressourcen, som vi ikke ser i tilfældet med Btrfs. Tja, forestil dig, at du kom til butikken for at købe et ur for ikke at komme for sent på arbejde, og i stedet for et ur solgte de dig en elektrisk grill med en timer i højst 30 minutter. Så situationen med Btrfs er endnu værre.
Når jeg kigger igennem mailinglister, støder jeg ofte på udsagnet om, at effektiv styring af diskplads ikke længere er relevant på grund af drevets billighed. Det er fuldstændig nonsens. Uden en effektiv diskpladsadministrator bliver operativsystemet sårbart og ubrugeligt. Uanset kapaciteten på diskene på din maskine.
Jeg vil gerne bede om en kommentar til afbrydelsen af Btrfs support i RHEL.
Der er ikke noget særligt at kommentere her, alt er meget klart. De havde det også som et "technology preview". Så jeg gik ikke igennem denne meget "forhåndsvisning". Lad ikke denne etiket hænge for evigt! Men de kan ikke lancere et mangelfuldt by-design produkt med fuld support. RHEL er en virksomhed, det vil sige foreskrevne vare-penge-forhold. Red Hat kan ikke mobbe brugere, som de gør på Btrfs-mailinglisten. Bare forestil dig situationen: en klient, der betalte sine hårdt tjente penge for disken og også dig for support, ønsker at forstå, hvor hans diskplads blev af, efter at han ikke skrev noget ned. Hvad vil du svare ham til dette?
Yderligere. Red Hats kunder omfatter velkendte store banker og børser. Forestil dig, hvad der ville ske, hvis de blev udsat for DoS-angreb baseret på den nævnte sårbarhed i Btrfs. Hvem tror du er ansvarlig for dette? Til dem, der er ved at pege fingeren på linjen i GPL-licensen, hvor der står, at forfatteren ikke er ansvarlig for noget, vil jeg straks sige: "skjul det væk!" Red Hat vil svare, og det på en sådan måde, at det ikke virker nok! Men jeg ved, at Red Hat ikke står over for denne form for problemer, givet deres særligt stærke hold af QA-ingeniører, som jeg havde mulighed for at arbejde tæt sammen med i min tid.
Hvorfor fortsætter nogle virksomheder med at understøtte Btrfs i deres virksomhedsprodukter?
Bemærk venligst, at præfikset "virksomhed" i produktnavnet ikke betyder meget. Enterprise er et mål for ansvar, der er indlejret i kontraktforholdet med kunden. Jeg kender kun én virksomhed baseret på GNU/Linux - RHEL. Alt andet præsenteres fra mit synspunkt kun som en virksomhed, men er ikke én. Og endelig, hvis der er efterspørgsel efter noget, så vil der altid være et udbud (i vores tilfælde er dette den nævnte "støtte"). Der er efterspørgsel på absolut alt, inkl. og ubrugelig software. Hvordan en sådan efterspørgsel dannes, og hvem der driver den, er et andet emne.
Så jeg vil ikke drage nogen konklusioner, efter at Facebook rygtes at have installeret Btrfs på sine servere. Desuden vil jeg anbefale omhyggeligt at holde adresserne på disse servere hemmelige af ovenstående årsager.
Hvorfor er der blevet brugt så meget på at rydde op i XFS-koden på det seneste? Når alt kommer til alt, er dette i første omgang et tredjeparts filsystem, og ext4 har været stabilt i lang tid og har kontinuitet fra tidligere lige så stabile versioner. Hvilken interesse har Red Hat i XFS? Giver det mening aktivt at udvikle to filsystemer, der har samme formål - ext4 og XFS?
Jeg kan ikke huske, hvad der motiverede dette. Det er meget muligt, at initiativet kom fra Red Hat-kunder. Jeg kan huske, at der blev udført forskning af denne art: På nogle filsystemer fra opstrøms blev der skabt et gigantisk antal objekter på avancerede drev af den nye generation. Ifølge resultaterne opførte XFS sig bedre end ext4. Så de begyndte at promovere det som det mest lovende. Jeg ville i hvert fald ikke lede efter noget sensationelt her.
For mig er det, som om de har erstattet en syl med sæbe. Det nytter ikke noget at udvikle ext4 og XFS. Både parallelt og hvilken som helst af dem at vælge imellem. Der kommer ikke noget godt ud af dette. Selvom der i naturen ofte er situationer, hvor der er et stort potentiale for vækst, men der er ikke plads til at vokse. I dette tilfælde opstår forskellige bizart grimme nye vækster, som alle peger fingeren på ("Åh, se, hvad du ikke vil se i dette liv!").
Tror du, at spørgsmålet om lagovertrædelse er blevet løst (i negativ forstand) med fremkomsten af krypteringsfunktioner i ext4, F2FS (for ikke at nævne RAID i Btrfs)?
Generelt er indførelsen af ethvert niveau og at træffe en beslutning om deres ikke-krænkelse normalt et spørgsmål om politik, og jeg forpligter mig ikke til at kommentere noget her. De objektive aspekter af lagovertrædelse er af ringe interesse for nogen, men vi kan overveje nogle af dem ved at bruge eksemplet med krænkelse "ovenfra", nemlig implementeringen i FS af funktionalitet, der allerede findes på bloklaget. En sådan "krænkelse" er berettiget med kun sjældne undtagelser. For hver sådan sag skal du først bevise to ting: at det virkelig er nødvendigt, og at systemets design ikke vil tage skade af at gøre det.
For eksempel giver spejling, som traditionelt har været en aktivitet for bloklaget, mening at implementere på filsystemniveau. Af forskellige årsager. For eksempel forekommer "tavs" datakorruption (bit rot) på diskdrev. Dette er, når enheden fungerer korrekt, men blokdataene uventet bliver beskadiget under påvirkning af et hårdt gammakvante udsendt af en fjern kvasar osv. Det værste er, hvis denne blok viser sig at være en FS-systemblok (superblok, bitmapblok, lagringstræknude osv.), for dette vil helt sikkert føre til kernepanik.
Bemærk venligst, at de spejle, der tilbydes af bloklaget (såkaldt RAID 1), ikke vil redde dig fra dette problem. Nå, virkelig: nogen bør tjekke kontrolsummerne og læse replikaen i tilfælde af fejl? Derudover giver det mening at spejle ikke bare alt, men kun metadataene. Nogle vigtige data (f.eks. eksekverbare filer af kritiske applikationer) kan gemmes som metadata. I dette tilfælde modtager de samme garantier for sikkerhed. Det giver mening at overlade beskyttelsen af de resterende data til andre undersystemer (måske endda brugerapplikationer) - vi har givet alle de nødvendige betingelser for dette.
Sådanne "økonomiske" spejle har ret til at eksistere, og de kan kun organiseres effektivt på filsystemniveau. Ellers er lagovertrædelse at rode i et undersystem med duplikeret kode af hensyn til nogle mikroskopiske fordele. Et slående eksempel på dette er implementeringen af RAID-5 ved hjælp af FS. Sådanne løsninger (egen RAID / LVM i filsystemet) dræber sidstnævnte i arkitektonisk henseende. Det skal også bemærkes her, at lagovertrædelser "sættes i drift" af forskellige former for marketingsvindlere. I mangel af ideer tilføjes funktionalitet, der længe har været implementeret på tilstødende niveauer, til undersystemerne, dette præsenteres som en ny ekstremt nyttig funktion og skubbes aktivt.
Reiser4 blev anklaget for at overtræde niveauerne "nedefra". Baseret på det faktum, at filsystemet ikke er monolitisk, som alle de andre, men modulopbygget, blev der lavet en uunderbygget antagelse om, at det gør, hvad niveauet ovenfor (VFS) skal gøre.
Er det muligt at tale om døden af ReiserFS v3.6 og for eksempel JFS? På det seneste har de næsten ikke fået opmærksomhed i kernen. Er de forældede?
Her skal vi definere, hvad et softwareprodukts død betyder. På den ene side er de brugt med succes (det er trods alt det, de er skabt til), hvilket betyder, at de lever. På den anden side kan jeg ikke tale for JFS (jeg ved ikke meget), men ReiserFS (v3) er meget svær at tilpasse til nye trends (testet i praksis). Det betyder, at udviklere i fremtiden ikke vil være opmærksomme på det, men på dem, der er lettere at tilpasse. Fra denne side viser det sig, at den desværre er død i arkitektonisk henseende. Jeg ville overhovedet ikke manipulere begrebet "moralsk forældet". Det gælder for eksempel godt til en garderobe, men ikke for softwareprodukter. Der er et begreb om mindreværd og overlegenhed i noget. Jeg kan absolut sige, at ReserFS v3 nu er underlegen i forhold til Reiser4 i alt, men i nogle typer arbejdsbyrde er den overlegen i forhold til alle andre upstream-FS'er.
Kender du til udviklingen af FS Tux3 og HAMMER/HAMMER2 (FS for DragonFly BSD)?
Ja, vi ved det. I Tux3 var jeg engang interesseret i teknologien i deres snapshots (de såkaldte "version pointers"), men i Reiser4 vil vi højst sandsynligt gå en anden vej. Jeg har tænkt på at understøtte snapshots i lang tid og har endnu ikke besluttet, hvordan jeg skal implementere dem til simple Reiser4-volumener. Faktum er, at den nymodens "dovne" referencetællerteknik foreslået af Ohad Rodeh kun virker for B-træer. Vi har dem ikke. For de datastrukturer, der bruges i Reiesr4, er "dovne" tællere ikke defineret - for at introducere dem er det nødvendigt at løse visse algoritmiske problemer, som ingen har taget på sig endnu.
Ifølge HAMMER: Jeg læste en artikel fra skaberen. Ikke interesseret. Igen, B-træer. Denne datastruktur er håbløst forældet. Vi forlod det i forrige århundrede.
Hvordan vurderer du den voksende efterspørgsel efter netværksklynge-FS'er som CephFS/GlusterFS/etc? Betyder denne efterspørgsel et skift i udviklernes prioriteringer mod netværks-FS og utilstrækkelig opmærksomhed på lokal FS?
Ja, sådan et skift i prioriteter er sket. Udviklingen af lokale filsystemer er stagneret. Ak, at gøre noget væsentligt for lokale mængder er nu ret svært, og ikke alle kan gøre det. Ingen ønsker at investere i deres udvikling. Det er omtrent det samme som at bede en kommerciel organisation om at bevilge penge til matematisk forskning - uden nogen entusiasme vil de spørge dig, hvordan du kan tjene penge på et nyt teorem. Nu er en lokal FS noget, der på magisk vis dukker op "ud af boksen" og "altid burde virke", og hvis det ikke virker, forårsager det uadresseret brokken som: "Ja, hvad tænker de!"
Derfor den manglende opmærksomhed på lokale FS, selvom der stadig er meget arbejde på det område. Og ja, alle har vendt sig til distribueret lagring, som er bygget på basis af allerede eksisterende lokale filsystemer. Det er meget moderigtigt nu. Udtrykket "Big Data" forårsager et adrenalinsus for mange, og forbinder det med konferencer, workshops, store lønninger osv.
Hvor rimeligt er det i princippet at implementere netværksfilsystemet i kernerum frem for i brugerrum?
En meget fornuftig tilgang, som endnu ikke er implementeret nogen steder. Generelt er spørgsmålet om, i hvilket rum et netværksfilsystem skal implementeres, et "tveægget sværd." Nå, lad os se på et eksempel. Klienten registrerede data på en ekstern maskine. De faldt ind i hendes sidecache i form af beskidte sider. Dette er jobbet for et "tynd gateway" netværksfilsystem i kernerummet. Så vil operativsystemet før eller siden bede dig om at skrive disse sider til disken for at frigøre dem. Så kommer IO-videresendelse (afsende) netværk FS-modulet i spil. Det bestemmer hvilken servermaskine (servernode) disse sider vil gå til.
Derefter tager netværksstakken over (og, som vi ved, er den implementeret i kernerummet). Dernæst modtager servernoden den pakke med data eller metadata og instruerer backend-lagermodulet (dvs. den lokale FS, der opererer i kernerummet) om at optage alt dette. Så vi har reduceret spørgsmålet til, hvor "sende"- og "modtage"-modulerne skal fungere. Hvis nogle af disse moduler kører i brugerrum, vil dette uundgåeligt føre til kontekstskift (på grund af behovet for at bruge kernetjenester). Antallet af sådanne switche afhænger af implementeringsdetaljerne.
Hvis der er mange sådanne switche, vil lagergennemstrømningen (I/O-ydelse) falde. Hvis dit backend-lager består af langsomme diske, vil du ikke bemærke et væsentligt fald. Men hvis du har hurtige diske (SSD, NVRAM osv.), så bliver kontekstskift allerede en "flaskehals", og ved at spare på kontekstskift kan ydeevnen øges markant. Standardmåden at spare penge på er at flytte moduler ind i kernerummet. For eksempel fandt vi ud af, at flytning af 9p-serveren fra QEMU til kernen på værtsmaskinen fører til en tredobling af VirtFS-ydeevnen.
Dette er selvfølgelig ikke et netværk FS, men det afspejler fuldt ud essensen af tingene. Ulempen ved denne optimering er problemer med overførsel. For nogle kan det sidste være kritisk. For eksempel har GlusterFS ingen moduler i kernen overhovedet. Takket være dette fungerer det nu på mange platforme, inklusive NetBSD.
Hvilke koncepter kunne lokale FS'ere låne fra netværk og omvendt?
Nu om dage har netværks-FS'er som regel tilføjelser over lokale FS'er, så jeg forstår ikke helt, hvordan du kan låne noget fra sidstnævnte. Jamen, lad os faktisk overveje en virksomhed med 4 ansatte, hvor alle gør deres egne ting: en distribuerer, en anden sender, den tredje modtager, den fjerde butikker. Og spørgsmålet, hvad virksomheden kan låne af sin medarbejder, der opbevarer det, lyder på en eller anden måde forkert (det har allerede haft, hvad det kunne have lånt af ham i lang tid).
Men lokale FS'ere har meget at lære af netværk. For det første bør du lære af dem, hvordan man aggregerer logiske mængder på et højt niveau. Nu er den såkaldte "avancerede" lokale filsystemer samler logiske volumener udelukkende ved hjælp af "virtuel enhed"-teknologi lånt fra LVM (den samme infektiøse lagovertrædelse, som først blev implementeret i ZFS). Med andre ord, oversættelse af virtuelle adresser (bloknumre) til rigtige og tilbage sker på et lavt niveau (dvs. efter filsystemet har udstedt en I/O-anmodning).
Bemærk venligst, at tilføjelse og fjernelse af enheder til logiske volumener (ikke spejle) arrangeret på bloklaget fører til problemer, som leverandører af sådanne "funktioner" er beskedent tavse om. Jeg taler om fragmentering på rigtige enheder, som kan nå monstrøse værdier, mens alt er fint på en virtuel enhed. Men få mennesker er interesserede i virtuelle enheder: alle er interesserede i, hvad der sker på dine rigtige enheder. Men ZFS-lignende FS (såvel som enhver FS i forbindelse med LVM) virker kun med virtuelle diskenheder (tildel virtuelle diskadresser blandt ledige, defragmenter disse virtuelle enheder osv.). Og de aner ikke, hvad der sker på rigtige enheder!
Forestil dig nu, at du har nul fragmentering på den virtuelle enhed (det vil sige, at du kun har en gigantisk udstrækning, der bor der), du tilføjer en disk til din logiske volumen, og fjerner derefter en anden tilfældig disk fra din logiske diskenhed og balancerer derefter igen. Og så mange gange. Det er ikke svært at forestille sig, at på den virtuelle enhed vil du stadig have den samme udstrækning levende, men på rigtige enheder vil du ikke se noget godt.
Det værste er, at du ikke engang er i stand til at rette op på denne situation! Det eneste du kan gøre her er at bede filsystemet om at defragmentere den virtuelle enhed. Men hun vil fortælle dig, at alt er fantastisk der - der er kun et omfang, fragmentering er nul, og det kan ikke blive bedre! Så logiske volumener arrangeret på blokniveau er ikke beregnet til gentagen tilføjelse/fjernelse af enheder. På en god måde behøver du kun at samle et logisk volumen på blokniveau én gang, give det til filsystemet og så ikke gøre andet med det.
Derudover tillader kombinationen af uafhængige FS+LVM-undersystemer os ikke at tage hensyn til de forskellige karakterer af de drev, hvorfra logiske volumener aggregeres. Antag faktisk, at du har samlet et logisk volumen fra HDD og solid-state-enheder. Men så vil førstnævnte kræve defragmentering, og sidstnævnte vil ikke. For sidstnævnte skal du udstede anmodninger om kassering, men for førstnævnte ikke osv. I denne kombination er det imidlertid ret vanskeligt at påvise en sådan selektivitet.
Bemærk, at efter at have oprettet din egen LVM på filsystemet, bliver situationen ikke meget bedre. Desuden gør du ved at gøre dette faktisk en stopper for udsigten til nogensinde at forbedre det i fremtiden. Det er meget slemt. Forskellige typer drev kan leve på den samme maskine. Og hvis filsystemet ikke skelner mellem dem, hvem vil så?
Et andet problem ligger og venter på den såkaldte. "Write-Anywhere" filsystemer (dette inkluderer også Reiser4, hvis du har angivet den relevante transaktionsmodel under montering). Sådanne filsystemer skal levere defragmenteringsværktøjer, der er uden fortilfælde i deres magt. Og volumenmanageren på lavt niveau hjælper ikke her, men kommer kun i vejen. Faktum er, at med sådan en manager gemmer din FS et kort over gratis blokke af kun én enhed - en virtuel. Derfor kan du kun defragmentere en virtuel enhed. Det betyder, at din defragmenter vil fungere i lang, lang tid på et stort enkelt rum af virtuelle adresser.
Og hvis du har mange brugere, der laver tilfældige overskrivninger, vil den nyttige effekt af en sådan defragmenter blive reduceret til nul. Dit system vil uundgåeligt begynde at bremse, og du skal kun folde dine hænder foran den skuffende diagnose "brudt design". Flere defragmentere, der kører på det samme adresseområde, vil kun forstyrre hinanden. Det er en helt anden sag, hvis du vedligeholder dit eget kort over gratis blokke for hver rigtig enhed. Dette vil effektivt parallelisere defragmenteringsprocessen.
Men dette kan kun lade sig gøre, hvis du har en logisk volumenadministrator på højt niveau. Lokale filsystemer med sådanne ledere eksisterede ikke tidligere (i det mindste ved jeg ikke om dem). Kun netværksfilsystemer (for eksempel GlusterFS) havde sådanne administratorer. Et andet meget vigtigt eksempel er værktøjet Volume Integrity Check (fsck). Hvis du gemmer dit eget uafhængige kort over frie blokke for hvert undervolumen, kan proceduren for kontrol af et logisk volumen effektivt paralleliseres. Med andre ord skaleres logiske mængder med ledere på højt niveau bedre.
Derudover vil du med volumenadministratorer på lavt niveau ikke være i stand til at organisere fuldgyldige snapshots. Med LVM og ZFS-lignende filsystemer kan du kun tage lokale snapshots, men ikke globale snapshots. Lokale snapshots giver dig mulighed for øjeblikkeligt at rulle tilbage kun almindelige filoperationer. Og ingen der vil rulle tilbage operationer med logiske volumener (tilføje/fjerne enheder). Lad os se på dette med et eksempel. På et tidspunkt, når du har en logisk volumen på to enheder A og B, der indeholder 100 filer, tager du et øjebliksbillede af system S og opretter derefter yderligere hundrede filer.
Derefter tilføjer du enhed C til din volumen og til sidst ruller dit system tilbage til snapshot S. Spørgsmål: Hvor mange filer og enheder indeholder din logiske volumen efter rollback til S? Der vil være 100 filer, som du måske har gættet, men der vil være 3 enheder - det er de samme enheder A, B og C, selvom på det tidspunkt, hvor snapshottet blev oprettet, var der kun to enheder i systemet (A og B ). Operationen tilføj enhed C rullede ikke tilbage, og hvis du nu fjerner enhed C fra computeren, vil den ødelægge dine data, så før du sletter, skal du først udføre en dyr operation for at fjerne enheden fra den rebalancerede logiske volumen, hvilket vil sprede alle data fra enhed C til enhed A og B. Men hvis din FS understøttede globale snapshots, ville en sådan rebalancering ikke være påkrævet, og efter en øjeblikkelig tilbagerulning til S, kunne du sikkert fjerne enhed C fra computeren.
Så globale snapshots er gode, fordi de giver dig mulighed for at undgå den dyre fjernelse (tilføjelse) af en enhed fra en logisk volumen (til en logisk volumen) med en stor mængde data (selvfølgelig, hvis du husker at "snapshot" dit system på det rigtige tidspunkt). Lad mig minde dig om, at oprettelse af snapshots og tilbagerulning af filsystemet til dem er øjeblikkelige operationer. Spørgsmålet kan opstå: hvordan er det overhovedet muligt øjeblikkeligt at rulle en operation tilbage på et logisk volumen, der tog dig tre dage? Men det er muligt! Forudsat at dit filsystem er designet korrekt. Jeg kom på ideen om sådanne "3D-snapshots" for tre år siden, og sidste år patenterede jeg denne teknik.
Den næste ting, som lokale FS'ere bør lære af netværk, er at gemme metadata på separate enheder på samme måde, som netværk FS'er gemmer dem på separate maskiner (de såkaldte metadataservere). Der er applikationer, der primært arbejder med metadata, og disse applikationer kan accelereres kraftigt ved at placere metadataene på dyre højtydende lagerenheder. Med FS+LVM-kombinationen vil du ikke være i stand til at demonstrere en sådan selektivitet: LVM ved ikke, hvad der er på den blok, du har sendt til den (data der eller metadata).
Du vil ikke få meget udbytte af at implementere din egen lav-niveau LVM i FS sammenlignet med FS+LVM kombinationen, men hvad du kan gøre meget godt er at rode FS, så det senere bliver umuligt at arbejde med dens kode. ZFS og Btrfs, der skyndte sig med virtuelle enheder, er alle klare eksempler på, hvordan lagovertrædelse dræber systemet i arkitektonisk henseende. Så hvorfor er jeg alt dette? Desuden er der ingen grund til at installere din egen lav-niveau LVM i filsystemet. I stedet skal du samle enheder til logiske volumener på et højt niveau, som nogle netværksfilsystemer gør med forskellige maskiner (lagernoder). Sandt nok gør de dette modbydeligt på grund af brugen af dårlige algoritmer.
Eksempler på helt forfærdelige algoritmer er DHT-oversætteren i filsystemet GlusterFS og det såkaldte CRUSH-kort i Ceph-filsystemet. Ingen af de algoritmer, jeg så, tilfredsstillede mig med hensyn til enkelhed og god skalerbarhed. Så jeg skulle huske algebra og opfinde alt selv. I 2015, mens jeg eksperimenterede med bundles over hash-funktioner, fandt jeg på og patenterede noget, der passer mig. Nu kan jeg sige, at forsøget på at omsætte alt dette i praksis var vellykket. Jeg kan ikke se nogen problemer med skalerbarhed i den nye tilgang.
Ja, hver undervolumen kræver en separat struktur, såsom en superblok i hukommelsen. Er det her meget skræmmende? Generelt ved jeg ikke, hvem der skal "koge havet" og skabe logiske mængder af hundredtusindvis eller flere enheder på en lokal maskine. Hvis nogen kan forklare mig dette, vil jeg være meget taknemmelig. I mellemtiden er det for mig markedsførings-bullshit.
Hvordan påvirkede ændringer i kerneblokenhedsundersystemet (for eksempel udseendet af blk-mq) kravene til FS-implementering?
De havde ingen indflydelse. Jeg ved ikke, hvad der ville ske på bloklaget, der ville gøre det nødvendigt at designe en ny FS. Interaktionsgrænsefladen for disse delsystemer er meget dårlig. Fra førersiden bør FS kun blive påvirket af udseendet af nye typer drev, som bloklaget vil blive justeret til først, og derefter FS (for reiser4 vil dette betyde udseendet af nye plugins).
Betyder fremkomsten af nye typer medier (for eksempel SMR eller allestedsnærværende SSD'er) fundamentalt nye udfordringer for filsystemdesign?
Ja. Og det er normale incitamenter for udviklingen af FS. Udfordringer kan være anderledes og helt uventede. For eksempel har jeg hørt om drev, hvor hastigheden af en I/O-operation er meget afhængig af størrelsen af et stykke data og dets offset. I Linux, hvor størrelsen af FS-blokken ikke kan overstige sidestørrelsen, vil et sådant drev som standard ikke vise sine fulde muligheder. Men hvis dit filsystem er designet korrekt, så er der en chance for at få meget mere ud af det.
Hvor mange mennesker arbejder i øjeblikket med Reiser4-koden udover dig?
Mindre end jeg gerne ville, men jeg oplever heller ikke akut mangel på ressourcer. Jeg er mere end tilfreds med udviklingstempoet for Reiser4. Jeg vil ikke "drive heste" - dette er ikke det rigtige område. Her, "hvis du kører mere stille, så fortsætter du!" Et moderne filsystem er det mest komplekse kerneundersystem, hvis forkerte designbeslutninger kan fortryde efterfølgende års menneskeligt arbejde.
Ved at tilbyde frivillige at gennemføre noget, garanterer jeg altid, at indsatsen helt sikkert fører til det rigtige resultat, som kan efterspørges ved seriøse behov. Som du forstår, kan der ikke være mange sådanne garantier på én gang. Samtidig kan jeg ikke fordrage "figurer", der skam promoverer "funktioner" af åbenlyst ubrugelig software, bedrager hundredvis af brugere og udviklere og samtidig sidder og smiler til kernel topmøder.
Har nogen virksomhed udtrykt vilje til at støtte udviklingen af Reiser4?
Ja, der var sådanne forslag, inkl. og fra en større leverandør. Men for dette måtte jeg flytte til et andet land. Desværre er jeg ikke længere 30 år gammel, jeg kan ikke bryde væk og gå sådan ved første fløjt.
Hvilke funktioner mangler i øjeblikket fra Reiser4?
Der er ingen "ændre størrelse"-funktion for simple volumener, svarende til den, der findes i ReiserFS(v3). Derudover ville filoperationer med DIRECT_IO-flaget ikke skade. Dernæst vil jeg gerne kunne adskille et bind i "semantiske underbind", som ikke har en fast størrelse, og som kan monteres som selvstændige bind. Disse problemer er gode for begyndere, der ønsker at prøve deres hånd på den "rigtige vare".
Og endelig vil jeg gerne have netværkslogiske volumener med enkel implementering og administration (moderne algoritmer tillader allerede dette). Men hvad Reiser4 helt sikkert aldrig vil have, er RAID-Z, scrubs, ledig plads caches, 128-bit variabler og andet markedsførings-sludder, der opstod på baggrund af mangel på ideer blandt udviklerne af nogle filsystemer.
Kan alt, hvad der er nødvendigt, implementeres af plugins?
Hvis vi kun taler om grænseflader og plugins (moduler), der implementerer dem, så er det ikke alt. Men hvis du også introducerer relationer på disse grænseflader, så vil du blandt andet have begreberne højere polymorfier, som du allerede kan klare dig med. Forestil dig, at du hypotetisk frøs et objektorienteret runtime-system, ændrede værdien af instruktionsmarkøren til at pege på et andet plugin, der implementerer den samme X-grænseflade, og derefter frigjorde systemet, så det fortsætter med at udføre.
Hvis slutbrugeren ikke bemærker sådan en "substitution", så siger vi, at systemet har nul-ordens polymorfi i X-grænsefladen (eller systemet er heterogent i X-grænsefladen, hvilket er det samme). Hvis du nu ikke kun har et sæt grænseflader, men også har relationer på dem (grænsefladegraf), så kan du introducere polymorfismer af højere orden, som vil karakterisere heterogeniteten af systemet allerede i "nabolaget" af enhver grænseflade. Jeg introducerede sådan en klassificering for længe siden, men det skete desværre aldrig.
Så ved hjælp af plugins og sådanne højere polymorfismer kan du beskrive enhver kendt funktion, samt "forudsige" dem, der aldrig engang er blevet nævnt. Jeg har ikke været i stand til strengt at bevise dette, men jeg kender heller ikke et modeksempel endnu. Generelt mindede dette spørgsmål mig om Felix Kleins "Erlangen-program". På et tidspunkt forsøgte han at repræsentere al geometri som en gren af algebra (specifikt gruppeteori).
Nu til hovedspørgsmålet - hvordan går det med promoveringen af Reiser4 til hovedkernen? Var der nogen publikationer om arkitekturen af dette filsystem, som du talte om i det sidste interview? Hvor relevant er dette spørgsmål fra dit synspunkt?
Generelt har vi bedt om optagelse i hovedgrenen i tre år. Reisers sidste kommentar i den offentlige tråd, hvor pull-anmodningen blev fremsat, forblev ubesvaret. Så alle yderligere spørgsmål er ikke til os. Jeg forstår personligt ikke, hvorfor vi skal "fusionere" til et specifikt operativsystem. På Linux konvergerede lyset ikke som en kile. Så der er et separat lager, hvor der vil være flere branch-porte til forskellige OS'er. Den, der har brug for det, kan klone den tilsvarende port og gøre, hvad du vil med den (naturligvis inden for licensen). Nå, hvis nogen ikke har brug for det, så er det ikke mit problem. På dette tidspunkt foreslår jeg at overveje spørgsmålet om "fremme til Linux-hovedkernen" som afgjort.
Publikationer om FS-arkitektur er relevante, men indtil videre har jeg kun fundet tid til mine nye resultater, som jeg anser for at være en højere prioritet. En anden ting er, at jeg er matematiker, og i matematik er enhver publikation et resumé af teoremer og deres beviser. At offentliggøre noget der uden bevis er et tegn på dårlig smag. Hvis jeg grundigt beviser eller afkræfter ethvert udsagn om FS's arkitektur, så bliver resultatet sådanne bunker, at det bliver ret svært at komme igennem. Hvem har brug for det? Det er sandsynligvis derfor, at alt bliver ved med at forblive i sin gamle form - kildekoden og kommentarer til den.
Hvad er nyt i Reiser4 i løbet af de sidste par år?
Den længe ventede stabilitet er endelig blevet til virkelighed. En af de sidste, der dukkede op, var en fejl, der førte til mapper, der ikke kunne slettes. Vanskeligheden var, at den kun dukkede op på baggrund af navnehash-kollisioner og med en bestemt placering af mappeposter i en træknude. Jeg kan dog stadig ikke anbefale Reiser4 til produktion: for dette skal du arbejde med aktiv interaktion med produktionssystemadministratorer.
Det lykkedes os endelig at implementere vores mangeårige idé - forskellige transaktionsmodeller. Tidligere kørte Reiser4 kun én hårdkodet Macdonald-Reiser-model. Dette skabte designproblemer. Især er snapshots ikke mulige i en sådan transaktionsmodel - de vil blive ødelagt af en atomkomponent kaldet "OVERWRITE SET". Reiser4 understøtter i øjeblikket tre transaktionsmodeller. I en af dem (Write-Anywhere) inkluderer atomkomponenten OVERWRITE SET kun systemsider (billeder af diskbitmaps osv.), som ikke kan "fotograferes" (høne- og ægproblemet).
Så billederne kan nu realiseres på den bedst mulige måde. I en anden transaktionsmodel går alle ændrede sider kun til OVERSKRIV SÆT (det vil sige, at det i det væsentlige er ren journalisering). Denne model er for dem, der klagede over den hurtige fragmentering af Reiser4-partitioner. Nu i denne model vil din partition ikke fragmenteres hurtigere end med ReiserFS (v3). Alle tre eksisterende modeller, med nogle forbehold, garanterer atomiciteten af operationer, men modeller med tab af atomicitet og kun bevarelse af sektionens integritet kan også være nyttige. Sådanne modeller kan være nyttige til alle slags applikationer (databaser osv.), som allerede har påtaget sig nogle af disse funktioner. Det er meget nemt at tilføje disse modeller til Reiser4, men jeg gjorde det ikke, fordi ingen spurgte mig, og jeg har personligt ikke brug for det.
Metadata-kontrolsummer dukkede op, og jeg har for nylig suppleret dem med "økonomiske" spejle" (stadig ustabilt materiale). Hvis kontrolsummen af en blok mislykkes, læser Reiser4 straks den tilsvarende blok fra replika-enheden. Bemærk, at ZFS og Btrfs ikke kan gøre dette: designet tillader det ikke. Der skal du køre en speciel baggrundsscanningsproces kaldet "scrub" og vente på, at den kommer til den problematiske blok. Programmører kalder billedligt sådanne begivenheder "krykker".
Og endelig er der dukket heterogene logiske volumener op, der tilbyder alt, hvad ZFS, Btrfs, bloklag, såvel som FS+LVM-kombinationer i princippet ikke kan give - parallel skalering, O(1) diskadresseallokator, transparent datamigrering mellem undervolumener. Sidstnævnte har også en brugergrænseflade. Nu kan du nemt flytte de hotteste data til det højeste ydeevne drev på din diskenhed.
Derudover er det muligt hurtigt at tømme eventuelle beskidte sider til et sådant drev, og derved fremskynde applikationer, der ofte kalder fsync(2), markant. Jeg bemærker, at bloklagsfunktionaliteten, kaldet bcache, slet ikke giver en sådan handlefrihed. Nye logiske volumener er baseret på mine algoritmer (der er tilsvarende patenter). Softwaren er allerede ret stabil, det er meget muligt at prøve det, måle ydeevne osv. Den eneste ulempe er, at du indtil videre skal opdatere volumenkonfigurationen manuelt og gemme den et sted.
Indtil videre har jeg været i stand til at implementere mine ideer med 10 pct.. Det er dog lykkedes mig, hvad jeg betragtede som det sværeste - at forbinde logiske volumener med en flash-procedure, der udfører alle udskudte handlinger i reiser4. Dette er alt sammen stadig i den eksperimentelle "format41"-gren.
Består Reiser4 xfstests?
Det gjorde det i hvert fald for mig, da jeg forberedte den sidste udgivelse.
Er det i princippet muligt at gøre Reiser4 til et netværk (cluster) FS ved hjælp af plugins?
Det er muligt, og endda nødvendigt! Hvis du opretter en netværksfil baseret på et korrekt designet lokalt filsystem, vil resultatet være meget imponerende! I moderne netværks-FS'er er jeg ikke tilfreds med tilstedeværelsen af et backend-lagerniveau, som er implementeret ved hjælp af enhver lokal FS. Eksistensen af dette niveau er fuldstændig uberettiget. Netværket FS skal interagere direkte med bloklaget og ikke bede den lokale FS om at oprette andre servicefiler!
Generelt er opdeling af filsystemer i lokale og netværk fra det onde. Det opstod på grund af ufuldkommenhederne i de algoritmer, der blev brugt for tredive år siden, og som intet er blevet foreslået i stedet for endnu. Dette er også grunden til fremkomsten af en masse unødvendige softwarekomponenter (forskellige tjenester osv.). På en god måde bør der kun være én FS i form af et kernemodul og et sæt brugerværktøjer installeret på hver maskine - en klyngenode. Denne FS er både lokal og netværk. Og intet mere!
Hvis intet lykkes med Reiser4 på Linux, vil jeg gerne tilbyde en FS til FreeBSD (citat fra et tidligere interview: “...FreeBSD... har akademiske rødder... Og det betyder, at vi med en høj grad af sandsynlighed vil finde et fælles sprog med udviklerne”) ?
Så, som vi lige har fundet ud af, har alt allerede fungeret perfekt med Linux: der er en separat fungerende Reiser4-port til det i form af en mastergren af vores lager. Jeg har ikke glemt FreeBSD! Tilbud! Jeg er klar til at arbejde tæt sammen med dem, der kender FreeBSD's indre godt. Forresten: Det, jeg virkelig godt kan lide ved deres samfund, er, at beslutninger dér bliver truffet af et opdateret råd af uafhængige eksperter, som ikke har noget at gøre med regeringens bedrag af én permanent person.
Hvordan vurderer du Linux-brugerfællesskabet i dag? Er det blevet mere "pop"?
I betragtning af mit arbejdes karakter er det ret svært for mig at vurdere dette. For det meste kommer brugere til mig med fejlrapporter og anmodninger om at rette sektionen. Brugere som brugere. Nogle er mere kyndige, andre mindre. Alle bliver behandlet ens. Nå, hvis brugeren ignorerer mine instruktioner, så undskyld mig: Ignoreringsrækkefølgen vil også blive indtastet fra min side.
Er det muligt at forudsige udviklingen af filsystemer for de næste fem til ti år? Hvad tror du er de vigtigste udfordringer, som FS-udviklere kan stå over for?
Ja, det er ikke svært at lave sådan en prognose. Der har ikke været udvikling af filsystemer i upstream i lang tid. Kun udseendet af en sådan skabes. Udviklere af lokale filsystemer løb ind i problemer forbundet med dårligt design. Her skal der tages forbehold. Jeg anser ikke den såkaldte "lagring", "slikning" og portering af kode for at være udvikling og udvikling. Og jeg klassificerer ikke misforståelsen kaldet "Btrfs" som en udvikling af de grunde, som jeg allerede har forklaret.
Hvert plaster gør kun sine problemer værre. Godt. og der er altid forskellige slags "evangelister", for hvem "alt virker." Grundlæggende er der tale om skolebørn og studerende, der springer forelæsninger over. Forestil dig bare: det virker for ham, men det gør professoren ikke. Sikke et adrenalinsus det her er! Fra mit synspunkt er den største skade forårsaget af "håndværkerne", der skyndte sig entusiastisk at "skrue" de vidunderlige funktioner i Btrfs på alle mulige lag som systemd, docker osv. - det ligner allerede metastaser.
Lad os nu prøve at lave en prognose for fem til ti år. Jeg har allerede kort listet, hvad vi vil lave i Reiser4. Den største udfordring for lokale FS-udviklere fra opstrømssiden vil være (ja, det er det allerede blevet) manglende evne til at udføre et anstændigt arbejde for en løn. Uden nogen ideer inden for datalagring, vil de fortsætte med at forsøge at patche disse uheldige VFS, XFS og ext4. Situationen med VFS ser især komisk ud på denne baggrund, der minder om den vanvittige modernisering af en restaurant, hvor der ikke er kokke, og der ikke forventes kokke.
Nu låser VFS-koden uden nogen betingelser flere hukommelsessider på samme tid og inviterer den underliggende FS til at operere på dem. Dette blev introduceret for at forbedre Ext4s ydeevne på sletningsoperationer, men som det er let at forstå, er en sådan samtidig låsning fuldstændig uforenelig med avancerede transaktionsmodeller. Det vil sige, at du ikke blot vil være i stand til at tilføje understøttelse af et eller andet smart filsystem i kernen. Jeg ved ikke, hvordan situationen er i andre områder af Linux, men hvad angår filsystemer, er det usandsynligt, at enhver udvikling her vil være forenelig med den politik, Torvalds fører i praksis (akademiske projekter bliver smidt ud, og svindlere, som aner ikke, hvad et B-træ, endeløse tillidskreditter udstedes). Derfor blev der sat kurs mod langsomt forfald. Selvfølgelig vil de forsøge med al deres magt at afgive det som "udvikling".
Ydermere vil "depoterne" af filsystemer, der indser, at du ikke kan tjene meget på "opbevaring" alene, forsøge sig med en mere profitabel forretning. Disse er som regel distribuerede filsystemer og virtualisering. Måske vil de portere den fashionable ZFS et andet sted, hvor den ikke eksisterer endnu. Men det, som alle FS fra opstrøms, ligner et nytårstræ: hvis du kan hænge nogle andre små ting ovenpå, så kan du ikke komme dybere. Jeg indrømmer, at det er muligt at bygge et seriøst virksomhedssystem baseret på ZFS, men da vi nu diskuterer fremtiden, kan jeg desværre kun konstatere, at ZFS er håbløs i denne henseende: med deres virtuelle enheder har fyrene afskåret ilten for dem selv og kommende generationer til videre udvikling. ZFS hører fortiden til. Og ext4 og XFS er ikke engang i forgårs.
Det er værd at nævne separat om det sensationelle koncept "Linux-filsystem af næste generation". Dette er et fuldstændigt politisk og marketingsprojekt skabt for så at sige muligheden for at "pinde fremtiden for filsystemer" i Linux bag specifikke karakterer. Faktum er, at Linux plejede at være "bare for sjov". Men nu er det primært en pengemaskine. De er lavet på alt muligt. For eksempel er det meget svært at skabe et godt softwareprodukt, men smarte "udviklere" har længe indset, at der overhovedet ikke er behov for at anstrenge sig: du kan med succes sælge ikke-eksisterende software, der blev annonceret og promoveret på alle mulige offentlige steder. begivenheder - det vigtigste er, at præsentationsdiasene skal indeholde flere "features".
Filsystemer er perfekte til dette, for du kan roligt prutte i ti år på resultatet. Nå, hvis nogen senere klager over manglen på netop dette resultat, så forstår han simpelthen ikke noget om filsystemer! Dette minder om en finansiel pyramide: Øverst er de eventyrere, der startede dette rod, og de få, der var "heldige": de "trak udbytte", dvs. modtaget penge til udvikling, fået et vellønnet job som ledere, "møkke op" til konferencer mv.
Dernæst kommer dem, der er "uheldige": de vil tælle tab, håndtere konsekvenserne af at implementere et ubrugeligt softwareprodukt i produktionen, "osv. Der er mange flere af dem. Nå, i bunden af pyramiden er der en enorm masse af udviklere, der "save" ubrugelig kode. De er de største tabere, for spildtid kan ikke returneres. Sådanne pyramider er yderst gavnlige for Torvalds og hans medarbejdere. Og jo flere af disse pyramider, jo bedre for dem. For at fodre sådanne pyramider kan alt tages ind i kernen. Selvfølgelig siger de det modsatte i offentligheden. Men jeg dømmer ikke efter ord, men efter handlinger.
Så "fremtiden for filsystemer i Linux" er endnu en meget fremmet, men næppe brugbar software. Efter Btrfs, med stor sandsynlighed, vil stedet for en sådan "fremtid" blive overtaget af Bcachefs, hvilket er endnu et forsøg på at krydse Linux-bloklaget med et filsystem (et dårligt eksempel er smitsomt). Og hvad er typisk: der er de samme problemer som i Btrfs. Jeg havde mistanke om dette i lang tid, og så kunne jeg på en eller anden måde ikke modstå og kiggede på koden - det er sandt!
Forfatterne af Bcachefs og Btrfs brugte aktivt andres kilder, da de skabte deres FS, og forstod lidt om dem. Situationen minder meget om børnenes spil "brudt telefon." Og jeg kan nogenlunde forestille mig, hvordan denne kode vil blive inkluderet i kernen. Faktisk vil ingen se "riverne" (alle vil træde på dem senere). Efter adskillige skænderier om kodens stil, beskyldninger om ikke-eksisterende overtrædelser osv., vil der blive draget en konklusion om forfatterens "loyalitet", hvor godt han "interagerer" med andre udviklere, og hvor vellykket alt dette kan derefter sælges til virksomheder.
Slutresultatet vil ikke interessere nogen. For tyve år siden ville jeg måske have været interesseret, men nu stilles spørgsmålene anderledes: Vil det være muligt at fremme dette, så visse personer bliver ansat inden for de næste ti år. Og desværre er det ikke sædvanligt at undre sig over slutresultatet.
Generelt vil jeg kraftigt fraråde at begynde at genopfinde dit filsystem fra bunden. For selv betydelige økonomiske investeringer vil ikke være nok til at få noget konkurrencedygtigt om ti år. Jeg taler selvfølgelig om seriøse projekter, og ikke om dem, der er beregnet til at blive "skubbet" ind i kernen. Så en mere effektiv måde at udtrykke dig på er at deltage i virkelige udviklinger, som os. Dette er selvfølgelig ikke let at gøre - men sådan er det med ethvert projekt på højt niveau.
Først skal du selvstændigt overvinde det problem, som jeg vil tilbyde. Hvorefter jeg, overbevist om alvoren i dine hensigter, vil begynde at hjælpe. Traditionelt bruger vi kun vores egen udvikling. Undtagelserne er komprimeringsalgoritmer og nogle hash-funktioner. Vi sender ikke udviklere for at rejse til konferencer, og så sidder vi ikke og kombinerer andres ideer ("måske hvad der sker"), som det er kutyme i de fleste startups.
Vi udvikler alle algoritmer selv. Jeg er i øjeblikket interesseret i de algebraiske og kombinatoriske aspekter af datalagringsvidenskab. Især endelige felter, asymptotik, bevis på uligheder. Der er også arbejde for almindelige programmører, men jeg skal advare dig med det samme: alle forslag om at "se på en anden FS og gøre det samme" ignoreres. Patches rettet mod tættere integration med Linux via VFS vil også gå der.
Så vi har ikke en rake, men vi har en forståelse for, hvor vi skal bevæge os, og vi har tillid til, at denne retning er den rigtige. Denne forståelse kom ikke i form af manna fra himlen. Lad mig minde dig om, at vi har 29 års udviklingserfaring bag os, to filsystemer skrevet fra bunden. Og det samme antal datagendannelsesværktøjer. Og det er meget!
Kilde: opennet.ru