Det andre intervjuet med Eduard Shishkin, utvikler av filsystemet Reiser4, er publisert.
For å begynne, vennligst minn leserne om hvor og hvem du jobber for.
Jeg jobber som hovedlagringsarkitekt ved Huawei Technologies, German Research Center. I virtualiseringsavdelingen tar jeg for meg ulike aspekter ved datalagring. Mine aktiviteter er ikke relatert til et spesifikt operativsystem.
Forplikter du deg for øyeblikket til hovedkjernegrenen?
Svært sjelden, og kun hvis min arbeidsgiver krever det. Sist gang var for omtrent tre år siden, sendte jeg patcher for å øke gjennomstrømningen for lagring som deles på verter ved å bruke 9p-protokollen (et annet navn for denne virksomheten er VirtFS). En viktig merknad må gjøres her: selv om jeg har jobbet med Linux i lang tid, har jeg aldri vært en fan av det, det vil si at jeg "puster jevnt", som med alt annet. Spesielt, hvis jeg oppdager en feil, kan jeg påpeke den på det meste én gang. Og slik at du så kan følge noen og overtale dem – dette vil ikke skje.
Jeg husker forrige gang, for ti år siden, du var ganske kritisk til kjerneutviklingsstilen. Fra ditt (eller kanskje bedriftens) synspunkt, har noe endret seg, har fellesskapet blitt mer responsivt eller ikke? Hvis ikke, hvem tror du har skylden?
Jeg har aldri sett noen endringer til det bedre. Fellesskapets hovedproblem er erstatningen av vitenskap med politisk teknologi, personlige forhold, majoritetsmening, populisme, råd fra "indre stemmer", råtne kompromisser, alt annet enn vitenskap. Datavitenskap, hva enn man kan si, er først og fremst en eksakt vitenskap. Og hvis noen begynner å proklamere sin egen verdi for 2x2, forskjellig fra 4, under "Linux way"-flagget, eller under et annet flagg, er det usannsynlig at dette vil føre til noe annet enn skade.
Alle problemer skyldes først og fremst inkompetanse og mangel på utdanning hos de som tar beslutninger. Hvis en leder er inhabil, er han ikke i stand til å ta en objektiv, tilstrekkelig beslutning. Hvis han også er ukulturert, er han ikke i stand til å finne en kompetent spesialist som vil gi ham de riktige rådene. Med stor sannsynlighet vil valget falle på en svindler som sier "tilsynelatende riktige ting." Et korrupt miljø utvikler seg alltid rundt inkompetente ensomme ledere. Dessuten kjenner historien ingen unntak i denne forbindelse, og fellesskapet er den klareste bekreftelsen på dette.
Hvordan vurderer du fremgangen i Btrfs-utviklingen? Ble denne FS kvitt barnesykdommer? Hvordan posisjonerer du det for deg selv - som en FS "til hjemmet" eller for bedriftsbruk også?
Jeg ble ikke kvitt det. Alt jeg nevnte for 11 år siden er fortsatt relevant i dag. Et av problemene med Btrfs som gjør den uegnet for seriøse behov er problemet med ledig plass. Jeg snakker ikke engang om det faktum at brukeren blir bedt om å løpe til butikken for en ny disk i situasjoner der en hvilken som helst annen FS vil vise mye ledig plass på partisjonen. Manglende evne til å fullføre en operasjon på et logisk volum på grunn av mangel på ledig plass er heller ikke det verste. Det verste er at en uprivilegert bruker nesten alltid kan omgå eventuelle diskkvoter, frata alle ledig plass på ganske kort tid.
Det ser slik ut (testet for Linux-kjerne 5.12). Et script lanseres på et nyinstallert system, som i en sløyfe lager filer med bestemte navn i hjemmekatalogen, skriver data til dem med visse forskyvninger, og deretter sletter disse filene. Etter et minutt med å kjøre dette skriptet, skjer det ingenting uvanlig. Etter fem minutter øker delen av den okkuperte plassen på partisjonen litt. Etter to til tre timer når den 50 % (med en startverdi på 15 %). Og etter fem eller seks timers arbeid krasjer skriptet med feilen "det er ingen ledig plass på partisjonen." Etter dette kan du ikke lenger skrive en 4K-fil til partisjonen din.
En interessant situasjon oppstår: du endte opp med å ikke skrive noe til partisjonen, og all ledig plass (ca. 85%) forsvant et sted. Analyse av en seksjon som er utsatt for et slikt angrep vil avsløre mange trenoder som inneholder bare ett element (et objekt utstyrt med en nøkkel), flere byte store. Det vil si at innholdet som tidligere okkuperte 15% av diskplassen viste seg å være jevnt "smurt" over hele partisjonen, slik at det ikke er noe sted å skrive en ny fil, fordi nøkkelen er større enn alle eksisterende, og den gratis blokker på partisjonen har gått tom.
Dessuten skjer alt dette allerede på den grunnleggende Btrfs-konfigurasjonen (uten noen øyeblikksbilder, undervolumer osv.), og det spiller ingen rolle hvordan du bestemmer deg for å lagre filkropper i den FS-en (som "fragmenter" i et tre, eller som utstrekninger av uformaterte blokker) - sluttresultatet vil være det samme.
Du vil ikke kunne utsette andre oppstrøms filsystemer for et slikt angrep (uansett hva de forteller deg). Jeg forklarte årsaken til problemet for lenge siden: dette er en fullstendig perversjon av B-tree-konseptet i Btrfs, som gjør det mulig for det å spontant eller med vilje degenerere. Spesielt, under visse belastninger, vil filsystemet ditt kontinuerlig "falle fra hverandre" under drift på egen hånd, uten hjelp utenfra. Det er klart at alle slags "trykkende" bakgrunnsprosesser vil redde dagen bare på individuelle skrivebord.
På kollektive servere vil en angriper alltid kunne "komme foran" dem. Systemadministratoren vil ikke engang kunne fastslå hvem som mobbet ham. Den raskeste måten å fikse dette problemet på i Btrfs er å gjenopprette strukturen til et vanlig B-tre, dvs. redesigne diskformatet og omskrive betydelige deler av Btrfs-koden. Dette vil ta 8-10 år, inkludert feilsøking, forutsatt at utviklerne strengt fulgte de originale artiklene om de relevante algoritmene og datastrukturene, og ikke spilte "broken phone"-spillet, slik det er vanlig (og oppmuntret) i "Linux". vei".
Her må vi også legge til tiden som kreves for at utviklere skal forstå alt dette. Det er her det blir vanskeligere. Uansett var ikke 10 år nok for dem å forstå. Vel, inntil da kan du ikke håpe på et mirakel. Det vil ikke skje i form av et monteringsalternativ "som du og jeg ikke visste om," eller i form av en oppdatering som "bare er et spørsmål om business" å forberede. For hver slik forhastet "fix" vil jeg presentere et nytt scenario med degenerasjon. B-trær er et av mine favorittemner, og jeg må si at disse strukturene ikke tåler friheter med seg selv!
Hvordan plasserer jeg Btrfs for meg selv? Som noe som absolutt ikke kan kalles et filsystem, enn si brukt. Fordi FS per definisjon er et OS-undersystem som er ansvarlig for effektiv styring av "diskplass"-ressursen, som vi ikke ser i tilfellet med Btrfs. Vel, forestill deg at du kom til butikken for å kjøpe en klokke for ikke å komme for sent på jobb, og i stedet for en klokke solgte de deg en elektrisk grill med timer i maksimalt 30 minutter. Så situasjonen med Btrfs er enda verre.
Når jeg ser gjennom e-postlister, kommer jeg ofte over påstanden om at effektiv administrasjon av diskplass ikke lenger er relevant på grunn av billigheten til stasjoner. Dette er fullstendig tull. Uten en effektiv diskplassbehandling vil operativsystemet bli sårbart og ubrukelig. Uavhengig av kapasiteten til diskene på maskinen din.
Jeg vil gjerne be om kommentar til avviklingen av Btrfs-støtte i RHEL.
Det er ikke noe spesielt å kommentere her, alt er veldig tydelig. De hadde det også som en "teknologi forhåndsvisning". Så jeg gikk ikke gjennom denne veldig "forhåndsvisningen". Ikke la denne etiketten henge for alltid! Men de kan ikke lansere et mangelfullt bydesign-produkt med full støtte. RHEL er et foretak, det vil si foreskrevne vare-pengeforhold. Red Hat kan ikke mobbe brukere slik de gjør på Btrfs e-postliste. Bare forestill deg situasjonen: en klient som betalte sine hardt opptjente penger for disken og også deg for støtte, ønsker å forstå hvor diskplassen hans ble av etter at han ikke skrev ned noe. Hva vil du svare ham på dette?
Lengre. Red Hats kunder inkluderer kjente store banker og børser. Tenk deg hva som ville skje hvis de ble utsatt for DoS-angrep basert på den nevnte sårbarheten i Btrfs. Hvem tror du er ansvarlig for dette? Til de som er i ferd med å peke fingeren på linjen i GPL-lisensen, hvor det står skrevet at forfatteren ikke er ansvarlig for noe, vil jeg umiddelbart si: "gjem det bort!" Red Hat vil svare, og på en slik måte at det ikke virker nok! Men jeg vet at Red Hat ikke står overfor denne typen problemer, gitt deres spesielt sterke team av QA-ingeniører som jeg hadde muligheten til å jobbe tett med i min tid.
Hvorfor fortsetter noen selskaper å støtte Btrfs i bedriftsproduktene sine?
Vær oppmerksom på at prefikset "bedrift" i produktnavnet ikke betyr mye. Foretak er et mål på ansvar innebygd i kontraktsforholdet med klienten. Jeg kjenner bare til én bedrift basert på GNU/Linux - RHEL. Alt annet, fra mitt ståsted, presenteres kun som et foretak, men er ikke ett. Og til slutt, hvis det er etterspørsel etter noe, vil det alltid være et tilbud (i vårt tilfelle er dette den nevnte "støtten"). Det er etterspørsel etter absolutt alt, inkl. og ubrukelig programvare. Hvordan en slik etterspørsel dannes og hvem som driver den er et annet tema.
Så jeg vil ikke trekke noen konklusjoner etter at Facebook ryktes å ha distribuert Btrfs på sine servere. Dessuten vil jeg anbefale å holde adressene til disse serverne hemmelige av de ovennevnte grunnene.
Hvorfor har det blitt lagt ned så mye arbeid i å rydde opp i XFS-koden i det siste? Tross alt er dette i utgangspunktet et tredjeparts filsystem, og ext4 har vært stabilt i lang tid og har kontinuitet fra tidligere like stabile versjoner. Hvilken interesse har Red Hat i XFS? Er det fornuftig å aktivt utvikle to filsystemer som er like i formål - ext4 og XFS?
Jeg husker ikke hva som motiverte dette. Det er godt mulig at initiativet kom fra Red Hat-kunder. Jeg husker at det ble utført forskning av denne typen: på noen filsystemer fra oppstrøms, ble det laget et gigantisk antall objekter på avanserte stasjoner av den nye generasjonen. I følge resultatene oppførte XFS seg bedre enn ext4. Så de begynte å promotere det som det mest lovende. Jeg ville i alle fall ikke se etter noe oppsiktsvekkende her.
For meg er det som om de har erstattet en syl med såpe. Det er ingen vits i å utvikle ext4 og XFS. Både parallelt og noen av dem å velge mellom. Det kommer ikke noe godt ut av dette. Selv om det ofte er situasjoner i naturen hvor det er mye potensial for vekst, men det er ikke plass til å vokse. I dette tilfellet oppstår forskjellige bisarre stygge nye vekster, som alle peker fingeren til ("Å, se, hva du ikke vil se i dette livet!").
Tror du problemet med lagbrudd har blitt avgjort (i negativ forstand) med bruken av krypteringsfunksjoner i ext4, F2FS (for ikke å snakke om RAID i Btrfs)?
Generelt sett er innføringen av nivåer og å ta en beslutning om ikke-brudd vanligvis et spørsmål om politikk, og jeg forplikter meg ikke til å kommentere noe her. De objektive aspektene ved lagbrudd er av liten interesse for noen, men vi kan vurdere noen av dem ved å bruke eksempelet på brudd "ovenfra", nemlig implementeringen i FS av funksjonalitet som allerede eksisterer på blokklaget. Et slikt "brudd" er berettiget med bare sjeldne unntak. For hvert slikt tilfelle må du først bevise to ting: at det virkelig trengs, og at utformingen av systemet ikke vil ta skade av å gjøre det.
For eksempel er speiling, som tradisjonelt har vært en aktivitet for blokklaget, fornuftig å implementere på filsystemnivå. Av forskjellige grunner. For eksempel forekommer "stille" datakorrupsjon (bitråte) på diskstasjoner. Dette er når enheten fungerer som den skal, men blokkdataene blir uventet skadet under påvirkning av et hardt gammakvante som sendes ut av en fjern kvasar, etc. Det verste er om denne blokken viser seg å være en FS-systemblokk (superblokk, bitmap-blokk, lagringstrenode, etc.), fordi dette vil helt sikkert føre til kjernepanikk.
Vær oppmerksom på at speilene som tilbys av blokklaget (såkalt RAID 1) ikke vil redde deg fra dette problemet. Vel, egentlig: noen burde sjekke sjekksummene og lese replikaen i tilfelle feil? I tillegg er det fornuftig å speile ikke bare alt, men bare metadataene. Noen viktige data (for eksempel kjørbare filer for kritiske applikasjoner) kan lagres som metadata. I dette tilfellet får de de samme garantiene for sikkerhet. Det er fornuftig å overlate beskyttelsen av de gjenværende dataene til andre undersystemer (kanskje til og med brukerapplikasjoner) - vi har gitt alle nødvendige betingelser for dette.
Slike "økonomiske" speil har rett til å eksistere, og de kan bare organiseres effektivt på filsystemnivå. Ellers er lagdelingsbrudd å fylle delsystemet med duplisert kode av hensyn til noen mikroskopiske fordeler. Et slående eksempel på dette er implementeringen av RAID-5 ved bruk av FS. Slike løsninger (egen RAID / LVM i filsystemet) dreper sistnevnte i arkitektonisk henseende. Det bør også bemerkes her at brudd på lagdeling blir "satt i drift" av ulike typer markedsføringssvindlere. I mangel av ideer, blir funksjonalitet som lenge har vært implementert på nabonivåer lagt til undersystemene, dette presenteres som en ny ekstremt nyttig funksjon og presses aktivt.
Reiser4 ble anklaget for å ha brutt nivåene "nedenfra". Basert på at filsystemet ikke er monolitisk, som alle de andre, men modulært, ble det gjort en ubegrunnet antagelse om at det gjør det nivået over (VFS) skal gjøre.
Er det mulig å snakke om døden til ReiserFS v3.6 og for eksempel JFS? I det siste har de nesten ikke fått oppmerksomhet i kjernen. Er de foreldet?
Her må vi definere hva døden til et programvareprodukt betyr. På den ene siden brukes de med hell (det er tross alt det de ble skapt for), noe som betyr at de lever. På den annen side kan jeg ikke snakke for JFS (jeg vet ikke så mye), men ReiserFS (v3) er veldig vanskelig å tilpasse seg nye trender (testet i praksis). Dette betyr at utviklere i fremtiden ikke vil ta hensyn til det, men til de som er lettere å tilpasse. Fra denne siden viser det seg at den dessverre er død i arkitektonisk henseende. Jeg ville ikke manipulert konseptet "moralsk foreldet" i det hele tatt. Det gjelder for eksempel godt for en garderobe, men ikke programvareprodukter. Det er et begrep om underlegenhet og overlegenhet i noe. Jeg kan absolutt si at ReserFS v3 nå er dårligere enn Reiser4 i alt, men i noen typer arbeidsbelastning er den overlegen alle andre oppstrøms FS-er.
Vet du om utviklingen av FS Tux3 og HAMMER/HAMMER2 (FS for DragonFly BSD)?
Ja, vi vet. I Tux3 var jeg en gang interessert i teknologien til øyeblikksbildene deres (de såkalte "versjonspekere"), men i Reiser4 vil vi mest sannsynlig gå en annen vei. Jeg har lenge tenkt på å støtte øyeblikksbilder og har ennå ikke bestemt meg for hvordan jeg skal implementere dem for enkle Reiser4-volumer. Faktum er at den nymotens "late" referansetellerteknikken foreslått av Ohad Rodeh bare fungerer for B-trær. Vi har dem ikke. For de datastrukturene som brukes i Reiesr4, er ikke "late" tellere definert - for å introdusere dem er det nødvendig å løse visse algoritmiske problemer, som ingen har tatt på seg ennå.
I følge HAMMER: Jeg leste en artikkel fra skaperen. Ikke interessert. Igjen, B-trær. Denne datastrukturen er håpløst utdatert. Vi forlot det i forrige århundre.
Hvordan vurderer du den økende etterspørselen etter nettverksklynge-FS-er som CephFS/GlusterFS/etc? Betyr dette kravet en endring i prioriteringene til utviklere mot nettverks-FS og utilstrekkelig oppmerksomhet til lokal FS?
Ja, et slikt prioriteringsskift har skjedd. Utviklingen av lokale filsystemer har stagnert. Akk, å gjøre noe vesentlig for lokale volumer er nå ganske vanskelig, og ikke alle kan gjøre det. Ingen ønsker å investere i utviklingen deres. Dette er omtrent det samme som å be en kommersiell organisasjon om å bevilge penger til matematisk forskning - uten noen entusiasme vil de spørre deg hvordan du kan tjene penger på et nytt teorem. Nå er en lokal FS noe som på magisk vis dukker opp "ut av boksen" og "skal alltid fungere", og hvis det ikke fungerer, forårsaker det uadressert grumling som: "Ja, hva tenker de!"
Derav mangelen på oppmerksomhet til lokale FS, selv om det fortsatt er mye arbeid på det området. Og ja, alle har vendt seg til distribuert lagring, som er bygget på grunnlag av allerede eksisterende lokale filsystemer. Det er veldig moteriktig nå. Uttrykket "Big Data" forårsaker et adrenalinrush for mange, og forbinder det med konferanser, workshops, høye lønninger, etc.
Hvor rimelig er det i prinsippet å implementere nettverksfilsystemet i kjerneplass i stedet for i brukerrom?
En svært fornuftig tilnærming som ennå ikke er implementert noe sted. Generelt er spørsmålet om hvor et nettverksfilsystem skal implementeres et "doeegget sverd." Vel, la oss se på et eksempel. Klienten registrerte data på en ekstern maskin. De falt inn i sidecachen hennes i form av skitne sider. Dette er jobben for et "tynn gateway" nettverksfilsystem i kjerneplass. Da vil operativsystemet før eller siden be deg om å skrive disse sidene til disk for å frigjøre dem. Da kommer IO-videresending (sending) nettverk FS-modulen inn i bildet. Den bestemmer hvilken servermaskin (servernode) disse sidene skal gå til.
Deretter tar nettverksstakken over (og, som vi vet, er den implementert i kjerneplass). Deretter mottar servernoden den pakken med data eller metadata og instruerer backend-lagringsmodulen (dvs. den lokale FS-en som opererer i kjerneplass) om å registrere alt dette. Så vi har redusert spørsmålet til hvor "sende"- og "mottaks"-modulene skal fungere. Hvis noen av disse modulene kjører i brukerområdet, vil dette uunngåelig føre til kontekstbytte (på grunn av behovet for å bruke kjernetjenester). Antall slike brytere avhenger av implementeringsdetaljene.
Hvis det er mange slike brytere, vil lagringskapasiteten (I/O-ytelse) reduseres. Hvis backend-lagringen din består av trege disker, vil du ikke merke et betydelig fall. Men hvis du har raske disker (SSD, NVRAM, etc.), blir kontekstbytte allerede en "flaskehals", og ved å spare på kontekstbytte kan ytelsen økes betydelig. Standardmåten å spare penger på er å flytte moduler til kjerneplass. For eksempel fant vi at flytting av 9p-serveren fra QEMU til kjernen på vertsmaskinen fører til en tredobling av VirtFS-ytelsen.
Dette er selvfølgelig ikke et nettverk FS, men det gjenspeiler essensen av ting fullt ut. Ulempen med denne optimaliseringen er problemer med portabilitet. For noen kan det siste være kritisk. For eksempel har GlusterFS ingen moduler i kjernen i det hele tatt. Takket være dette fungerer det nå på mange plattformer, inkludert NetBSD.
Hvilke konsepter kan lokale FS-er låne fra nettverk og omvendt?
I dag har nettverks-FS-er som regel tilleggsprogrammer over lokale FS-er, så jeg forstår ikke helt hvordan du kan låne noe fra sistnevnte. Vel, faktisk, la oss vurdere et selskap med 4 ansatte, der alle gjør sine egne ting: en distribuerer, en annen sender, den tredje mottar, den fjerde butikker. Og spørsmålet, hva kan selskapet låne av den ansatte som lagrer det, høres på en eller annen måte feil ut (det har allerede hatt det det kunne ha lånt av ham i lang tid).
Men lokale FS-er har mye å lære av nettverk. For det første bør du lære av dem hvordan du samler logiske volumer på et høyt nivå. Nå den såkalte "avanserte" lokale filsystemer samler logiske volumer utelukkende ved å bruke "virtuell enhet"-teknologi lånt fra LVM (det samme smittsomme lagbruddet som først ble implementert i ZFS). Med andre ord, oversettelse av virtuelle adresser (blokknumre) til reelle og tilbake skjer på et lavt nivå (dvs. etter at filsystemet har utstedt en I/O-forespørsel).
Vær oppmerksom på at å legge til og fjerne enheter til logiske volumer (ikke speil) arrangert på blokklaget fører til problemer som leverandører av slike "funksjoner" er beskjedent tause om. Jeg snakker om fragmentering på ekte enheter, som kan nå monstrøse verdier, mens på en virtuell enhet er alt bra. Imidlertid er få mennesker interessert i virtuelle enheter: alle er interessert i hva som skjer på de virkelige enhetene dine. Men ZFS-lignende FS (så vel som enhver FS i forbindelse med LVM) fungerer bare med virtuelle diskenheter (tildel virtuelle diskadresser blant ledige, defragmenter disse virtuelle enhetene, etc.). Og de aner ikke hva som skjer på ekte enheter!
Forestill deg nå at du har null fragmentering på den virtuelle enheten (det vil si at du bare har en gigantisk utstrekning som bor der), du legger til en disk i det logiske volumet ditt, og fjerner deretter en annen tilfeldig disk fra det logiske volumet ditt og balanserer deretter på nytt. Og så mange ganger. Det er ikke vanskelig å forestille seg at på den virtuelle enheten vil du fortsatt ha samme grad levende, men på ekte enheter vil du ikke se noe bra.
Det verste er at du ikke engang klarer å rette opp denne situasjonen! Det eneste du kan gjøre her er å be filsystemet om å defragmentere den virtuelle enheten. Men hun vil fortelle deg at alt er flott der - det er bare ett omfang, fragmentering er null, og det kan ikke bli bedre! Så logiske volumer arrangert på blokknivå er ikke ment for gjentatt tillegg/fjerning av enheter. På en god måte trenger du bare å sette sammen et logisk volum på blokknivå én gang, gi det til filsystemet, og så ikke gjøre noe annet med det.
I tillegg tillater ikke kombinasjonen av uavhengige FS+LVM-undersystemer oss å ta hensyn til den forskjellige naturen til stasjonene som logiske volumer aggregeres fra. Anta at du har satt sammen et logisk volum fra HDD og solid-state-enheter. Men da vil førstnevnte kreve defragmentering, og sistnevnte vil ikke. For sistnevnte må du sende forkastforespørsler, men for førstnevnte, ikke osv. I denne kombinasjonen er det imidlertid ganske vanskelig å demonstrere slik selektivitet.
Merk at etter å ha laget din egen LVM på filsystemet, blir ikke situasjonen mye bedre. Dessuten, ved å gjøre dette setter du faktisk en stopper for utsiktene til noen gang å forbedre det i fremtiden. Dette er veldig dårlig. Ulike typer stasjoner kan leve på samme maskin. Og hvis filsystemet ikke skiller mellom dem, hvem vil da gjøre det?
Et annet problem ligger og venter på den såkalte. "Write-Anywhere" filsystemer (dette inkluderer også Reiser4, hvis du spesifiserte riktig transaksjonsmodell under montering). Slike filsystemer må tilby defragmenteringsverktøy som er enestående i sin makt. Og volumbehandleren på lavt nivå hjelper ikke her, men kommer bare i veien. Faktum er at med en slik manager vil FS-en din lagre et kart over gratis blokker av bare én enhet - en virtuell. Følgelig kan du bare defragmentere en virtuell enhet. Dette betyr at defragmenteringen vil fungere i lang, lang tid på et stort enkelt rom med virtuelle adresser.
Og hvis du har mange brukere som gjør tilfeldige overskrivinger, vil den nyttige effekten av en slik defragmentering reduseres til null. Systemet ditt vil uunngåelig begynne å avta, og du trenger bare å folde hendene foran den skuffende diagnosen "ødelagt design". Flere defragmentere som kjører på samme adresseområde vil bare forstyrre hverandre. Det er en helt annen sak om du vedlikeholder ditt eget kart over gratisblokker for hver ekte enhet. Dette vil effektivt parallellisere defragmenteringsprosessen.
Men dette kan bare gjøres hvis du har en logisk volumbehandler på høyt nivå. Lokale filsystemer med slike ledere eksisterte ikke tidligere (i det minste vet jeg ikke om dem). Bare nettverksfilsystemer (for eksempel GlusterFS) hadde slike administratorer. Et annet veldig viktig eksempel er verktøyet volumintegritetssjekk (fsck). Hvis du lagrer ditt eget uavhengige kart over ledige blokker for hvert undervolum, kan prosedyren for å kontrollere et logisk volum effektivt paralleliseres. Med andre ord, logiske volumer med ledere på høyt nivå skaleres bedre.
I tillegg, med volumbehandlere på lavt nivå vil du ikke kunne organisere fullverdige øyeblikksbilder. Med LVM- og ZFS-lignende filsystemer kan du bare ta lokale øyeblikksbilder, men ikke globale øyeblikksbilder. Lokale øyeblikksbilder lar deg umiddelbart rulle tilbake bare vanlige filoperasjoner. Og ingen der vil rulle tilbake operasjoner med logiske volumer (legge til/fjerne enheter). La oss se på dette med et eksempel. På et tidspunkt, når du har et logisk volum på to enheter A og B som inneholder 100 filer, tar du et øyeblikksbilde av system S og lager deretter ytterligere hundre filer.
Etter det legger du til enhet C til volumet ditt, og til slutt ruller systemet tilbake til øyeblikksbilde S. Spørsmål: Hvor mange filer og enheter inneholder det logiske volumet ditt etter tilbakeføring til S? Det vil være 100 filer, som du kanskje har gjettet, men det vil være 3 enheter - dette er de samme enhetene A, B og C, selv om det bare var to enheter i systemet på det tidspunktet øyeblikksbildet ble opprettet (A og B ). Operasjonen legg til enhet C rullet ikke tilbake, og hvis du nå fjerner enhet C fra datamaskinen, vil den ødelegge dataene dine, så før du sletter må du først utføre en kostbar operasjon for å fjerne enheten fra det rebalanserte logiske volumet, som vil spre all data fra enhet C til enhetene A og B. Men hvis FS støttet globale øyeblikksbilder, ville slik rebalansering ikke være nødvendig, og etter en umiddelbar tilbakeføring til S, kan du trygt fjerne enhet C fra datamaskinen.
Så globale øyeblikksbilder er gode fordi de lar deg unngå kostbar fjerning (tilføyelse) av en enhet fra et logisk volum (til et logisk volum) med en stor mengde data (selvfølgelig, hvis du husker å "snapshot" systemet ditt på riktig tidspunkt). La meg minne deg på at å lage øyeblikksbilder og rulle tilbake filsystemet til dem er øyeblikkelige operasjoner. Spørsmålet kan oppstå: hvordan er det i det hele tatt mulig å øyeblikkelig rulle tilbake en operasjon på et logisk volum som tok deg tre dager? Men det er mulig! Forutsatt at filsystemet ditt er riktig utformet. Jeg kom på ideen om slike "3D-øyeblikksbilder" for tre år siden, og i fjor patenterte jeg denne teknikken.
Det neste lokale FS-er bør lære av nettverks-er er å lagre metadata på separate enheter på samme måte som nettverks-FS-er lagrer dem på separate maskiner (de såkalte metadataservere). Det finnes applikasjoner som primært jobber med metadata, og disse applikasjonene kan akselereres kraftig ved å plassere metadataene på dyre lagringsenheter med høy ytelse. Med FS+LVM-kombinasjonen vil du ikke kunne demonstrere slik selektivitet: LVM vet ikke hva som er på blokken du sendte til den (data der eller metadata).
Du vil ikke få mye nytte av å implementere din egen lav-nivå LVM i FS sammenlignet med FS+LVM-kombinasjonen, men det du kan gjøre veldig bra er å rote FS slik at det senere blir umulig å jobbe med koden. ZFS og Btrfs, som skyndte seg med virtuelle enheter, er alle klare eksempler på hvordan lagdelingsbrudd dreper systemet i arkitektoniske termer. Så hvorfor er jeg alt dette? Dessuten er det ikke nødvendig å bygge din egen lav-nivå LVM i filsystemet. I stedet må du samle enheter til logiske volumer på et høyt nivå, slik noen nettverksfilsystemer gjør med forskjellige maskiner (lagringsnoder). Riktignok gjør de dette motbydelig på grunn av bruken av dårlige algoritmer.
Eksempler på helt forferdelige algoritmer er DHT-oversetteren i filsystemet GlusterFS og det såkalte CRUSH-kartet i Ceph-filsystemet. Ingen av algoritmene jeg så tilfredsstilte meg med tanke på enkelhet og god skalerbarhet. Så jeg måtte huske algebra og finne på alt selv. I 2015, mens jeg eksperimenterte med bunter over hash-funksjoner, kom jeg på og patenterte noe som passer meg. Nå kan jeg si at forsøket på å sette alt dette ut i livet var vellykket. Jeg ser ingen problemer med skalerbarhet i den nye tilnærmingen.
Ja, hvert undervolum vil kreve en egen struktur, for eksempel en superblokk i minnet. Er dette veldig skummelt? Generelt vet jeg ikke hvem som skal "koke havet" og lage logiske volumer på hundretusener eller flere enheter på en lokal maskin. Hvis noen kan forklare meg dette, vil jeg være veldig takknemlig. I mellomtiden er dette markedsføringsbullshit for meg.
Hvordan påvirket endringer i kjerneblokkenhetens undersystem (for eksempel utseendet til blk-mq) kravene til FS-implementering?
De hadde ingen innvirkning. Jeg vet ikke hva som ville skje på blokklaget som ville gjøre det nødvendig å designe en ny FS. Interaksjonsgrensesnittet til disse delsystemene er svært dårlig. Fra førersiden skal FS kun påvirkes av utseendet til nye typer stasjoner, som blokklaget vil bli justert til først, og deretter FS (for reiser4 vil dette bety utseendet av nye plugins).
Betyr fremveksten av nye typer medier (for eksempel SMR, eller allestedsnærværende SSD-er) fundamentalt nye utfordringer for filsystemdesign?
Ja. Og dette er normale insentiver for utviklingen av FS. Utfordringer kan være annerledes og helt uventede. For eksempel har jeg hørt om stasjoner der hastigheten på en I/O-operasjon er svært avhengig av størrelsen på et datastykke og dets forskyvning. I Linux, hvor størrelsen på FS-blokken ikke kan overstige sidestørrelsen, vil en slik stasjon ikke vise sine fulle funksjoner som standard. Men hvis filsystemet ditt er utformet riktig, er det en sjanse til å få mye mer ut av det.
Hvor mange personer jobber for tiden med Reiser4-koden foruten deg?
Mindre enn jeg skulle ønske, men jeg opplever heller ikke akutt mangel på ressurser. Jeg er mer enn fornøyd med utviklingstakten til Reiser4. Jeg kommer ikke til å "drive hester" - dette er ikke det rette området. Her, "hvis du kjører roligere, vil du fortsette!" Et moderne filsystem er det mest komplekse kjerneundersystemet, hvis feil designbeslutninger kan angre påfølgende år med menneskelig arbeid.
Ved å tilby frivillige å gjennomføre noe, garanterer jeg alltid at innsatsen helt sikkert vil føre til riktig resultat, som kan etterspørres ved alvorlige behov. Som du forstår kan det ikke være mange slike garantier på en gang. Samtidig kan jeg ikke fordra "figurer" som skamløst fremmer "funksjoner" av åpenbart ubrukelig programvare, lurer hundrevis av brukere og utviklere, og samtidig sitter og smiler på kjernetoppmøter.
Har noen selskap uttrykt vilje til å støtte utviklingen av Reiser4?
Ja, det var slike forslag, bl.a. og fra en stor leverandør. Men for dette måtte jeg flytte til et annet land. Dessverre er jeg ikke lenger 30 år gammel, jeg kan ikke bryte meg løs og gå sånn ved første fløyte.
Hvilke funksjoner mangler for øyeblikket fra Reiser4?
Det er ingen «endre størrelse»-funksjon for enkle volumer, lik den som finnes i ReiserFS(v3). I tillegg ville ikke filoperasjoner med DIRECT_IO-flagget skade. Deretter ønsker jeg å kunne dele opp et volum i "semantiske undervolumer", som ikke har en fast størrelse, og som kan monteres som uavhengige volumer. Disse problemene er bra for nybegynnere som ønsker å prøve seg på den "ekte tingen".
Og til slutt vil jeg gjerne ha nettverkslogiske volumer med enkel implementering og administrasjon (moderne algoritmer tillater allerede dette). Men det Reiser4 definitivt aldri vil ha er RAID-Z, scrubs, ledig plass cacher, 128-bit variabler og annet markedsførings-tull som oppsto på bakgrunn av mangel på ideer blant utviklerne av enkelte filsystemer.
Kan alt som måtte være nødvendig implementeres av plugins?
Hvis vi bare snakker om grensesnitt og plugins (moduler) som implementerer dem, så ikke alt. Men hvis du også introduserer relasjoner på disse grensesnittene, så vil du blant annet ha begrepene høyere polymorfismer, som du allerede kan klare deg med. Tenk deg at du hypotetisk har fryst et objektorientert kjøretidssystem, endret verdien på instruksjonspekeren til å peke til en annen plugin som implementerer det samme X-grensesnittet, og deretter fryste systemet slik at det fortsetter å kjøre.
Hvis sluttbrukeren ikke legger merke til en slik "substitusjon", så sier vi at systemet har nullordens polymorfisme i X-grensesnittet (eller systemet er heterogent i X-grensesnittet, som er det samme). Hvis du nå ikke bare har et sett med grensesnitt, men også har relasjoner på dem (grensesnittgraf), kan du introdusere polymorfismer av høyere orden, som vil karakterisere heterogeniteten til systemet allerede i "nabolaget" til ethvert grensesnitt. Jeg introduserte en slik klassifisering for lenge siden, men det skjedde dessverre aldri.
Så, ved hjelp av plugins og slike høyere polymorfismer, kan du beskrive alle kjente funksjoner, samt "forutsi" de som aldri har blitt nevnt. Jeg har ikke klart å bevise dette, men jeg kjenner heller ikke til et moteksempel ennå. Generelt minnet dette spørsmålet meg om Felix Kleins "Erlangen-program". På en gang prøvde han å representere all geometri som en gren av algebra (nærmere bestemt gruppeteori).
Nå til hovedspørsmålet - hvordan går det med promoteringen av Reiser4 til hovedkjernen? Var det noen publikasjoner om arkitekturen til dette filsystemet som du snakket om i forrige intervju? Hvor relevant er dette spørsmålet fra ditt ståsted?
Generelt har vi bedt om inkludering i hovedgrenen i tre år. Reisers siste kommentar i den offentlige tråden der pull-forespørselen ble gjort forble ubesvart. Så alle ytterligere spørsmål er ikke for oss. Jeg personlig forstår ikke hvorfor vi trenger å "slå sammen" til et spesifikt operativsystem. På Linux konvergerte ikke lyset som en kile. Så det er et eget depot der det vil være flere grenporter for forskjellige operativsystemer. Den som trenger det kan klone den tilsvarende porten og gjøre hva du vil med den (innenfor lisensen, selvfølgelig). Vel, hvis noen ikke trenger det, så er det ikke mitt problem. På dette tidspunktet foreslår jeg å vurdere spørsmålet om "opprykk til hoved Linux-kjernen" som avgjort.
Publikasjoner om FS-arkitektur er aktuelle, men foreløpig har jeg bare funnet tid til mine nye resultater, som jeg anser som høyere prioritet. En annen ting er at jeg er matematiker, og i matematikk er enhver publikasjon et sammendrag av teoremer og deres bevis. Å publisere noe der uten bevis er et tegn på dårlig smak. Hvis jeg grundig beviser eller avkrefter en påstand om arkitekturen til FS, så blir resultatet slike hauger at det blir ganske vanskelig å komme gjennom. Hvem trenger det? Dette er sannsynligvis grunnen til at alt fortsetter å forbli i sin gamle form - kildekoden og kommentarer til den.
Hva er nytt i Reiser4 de siste årene?
Den etterlengtede stabiliteten har endelig materialisert seg. En av de siste som dukket opp var en feil som førte til "u-slettbare" kataloger. Vanskeligheten var at den bare dukket opp mot bakgrunnen av navnehash-kollisjoner og med en bestemt plassering av katalogposter i en trenode. Imidlertid kan jeg fortsatt ikke anbefale Reiser4 for produksjon: for dette må du jobbe med aktiv interaksjon med produksjonssystemadministratorer.
Vi klarte endelig å implementere vår mangeårige idé - forskjellige transaksjonsmodeller. Tidligere kjørte Reiser4 bare én hardkodet Macdonald-Reiser-modell. Dette skapte designproblemer. Spesielt er øyeblikksbilder ikke mulig i en slik transaksjonsmodell - de vil bli ødelagt av en atomkomponent kalt "OVERWRITE SET". Reiser4 støtter for tiden tre transaksjonsmodeller. I en av dem (Write-Anywhere) inkluderer atomkomponenten OVERWRITE SET bare systemsider (bilder av diskbitmaps osv.), som ikke kan "fotograferes" (kylling- og eggproblemet).
Så bildene kan nå realiseres på best mulig måte. I en annen transaksjonsmodell går alle modifiserte sider kun til OVERWRITE SET (det vil si at det i hovedsak er ren journalføring). Denne modellen er for de som klaget på den raske fragmenteringen av Reiser4-partisjoner. Nå i denne modellen vil partisjonen ikke fragmenteres raskere enn med ReiserFS (v3). Alle de tre eksisterende modellene, med noen forbehold, garanterer atomiteten til operasjoner, men modeller med tap av atomitet og kun bevaring av integriteten til seksjonen kan også være nyttige. Slike modeller kan være nyttige for alle typer applikasjoner (databaser osv.), som allerede har tatt på seg noen av disse funksjonene. Det er veldig enkelt å legge til disse modellene i Reiser4, men jeg gjorde det ikke, fordi ingen spurte meg, og jeg personlig trenger det ikke.
Metadatasjekksummer dukket opp, og jeg har nylig supplert dem med "økonomiske" speil" (fremdeles ustabilt materiale). Hvis kontrollsummen til en blokk mislykkes, leser Reiser4 umiddelbart den tilsvarende blokken fra replikaenheten. Merk at ZFS og Btrfs ikke kan gjøre dette: designet tillater det ikke. Der må du kjøre en spesiell bakgrunnsskanningsprosess kalt "skrubb" og vente til den kommer til den problematiske blokken. Programmerere kaller billedlig slike hendelser "krykker".
Og til slutt har heterogene logiske volumer dukket opp, som tilbyr alt som ZFS, Btrfs, blokklag, samt FS+LVM-kombinasjoner i prinsippet ikke kan gi - parallell skalering, O(1) diskadresseallokator, transparent datamigrering mellom undervolumer. Sistnevnte har også et brukergrensesnitt. Nå kan du enkelt flytte de heteste dataene til den høyeste ytelsen på volumet ditt.
I tillegg er det mulig å raskt skylle alle skitne sider til en slik stasjon, og dermed øke hastigheten på applikasjoner som ofte kaller fsync(2). Jeg legger merke til at blokklagsfunksjonaliteten, kalt bcache, ikke gir en slik handlingsfrihet i det hele tatt. Nye logiske volumer er basert på mine algoritmer (det finnes tilsvarende patenter). Programvaren er allerede ganske stabil, det er fullt mulig å prøve det, måle ytelse osv. Den eneste ulempen er at for nå må du manuelt oppdatere volumkonfigurasjonen og lagre den et sted.
Så langt har jeg klart å implementere ideene mine med 10 prosent, men jeg har lykkes med det jeg anså som det vanskeligste - å koble logiske volumer med en flash-prosedyre som utfører alle utsatte handlinger i reiser4. Alt dette er fortsatt i den eksperimentelle "format41"-grenen.
Klarer Reiser4 xfstests?
Det gjorde det i hvert fall for meg da jeg forberedte den siste utgivelsen.
Er det i prinsippet mulig å gjøre Reiser4 til et nettverk (cluster) FS ved hjelp av plugins?
Det er mulig, og til og med nødvendig! Hvis du lager en nettverksfil basert på et riktig utformet lokalt filsystem, vil resultatet være veldig imponerende! I moderne nettverks-FS-er er jeg ikke fornøyd med tilstedeværelsen av et backend-lagringsnivå, som er implementert ved hjelp av en hvilken som helst lokal FS. Eksistensen av dette nivået er fullstendig uberettiget. Nettverket FS må samhandle direkte med blokklaget, og ikke be den lokale FS om å lage andre tjenestefiler!
Generelt er det å dele filsystemer i lokale og nettverk fra det onde. Det oppsto fra ufullkommenhet i algoritmene som ble brukt for tretti år siden, og i stedet for som ingenting ennå er foreslått. Dette er også grunnen til utseendet til en masse unødvendige programvarekomponenter (ulike tjenester, etc.). På en god måte bør det bare være én FS i form av en kjernemodul og et sett med brukerverktøy installert på hver maskin – en klyngennode. Denne FS er både lokal og nettverk. Og ikke noe mer!
Hvis ingenting fungerer med Reiser4 på Linux, vil jeg gjerne tilby en FS for FreeBSD (sitat fra et tidligere intervju: “...FreeBSD... har akademiske røtter... Og dette betyr at vi med stor sannsynlighet vil finne et felles språk med utviklerne”) ?
Så, som vi nettopp fant ut, har alt allerede fungert perfekt med Linux: det er en egen fungerende Reiser4-port for det i form av en hovedgren av depotet vårt. Jeg har ikke glemt FreeBSD! By på! Jeg er klar til å jobbe tett med de som kjenner innsiden av FreeBSD godt. Forresten: Det jeg virkelig liker med deres fellesskap er at beslutninger der er tatt av et oppdatert råd av uavhengige eksperter, som ikke har noe å gjøre med regjeringens bedrag av én fast person.
Hvordan vurderer du Linux-brukerfellesskapet i dag? Har det blitt mer "pop"?
Med tanke på arbeidet mitt er det ganske vanskelig for meg å vurdere dette. For det meste kommer brukere til meg med feilrapporter og forespørsler om å fikse delen. Brukere som brukere. Noen er mer kunnskapsrike, noen mindre. Alle blir behandlet likt. Vel, hvis brukeren ignorerer instruksjonene mine, så unnskyld meg: Ignoreringsordren vil også bli lagt inn fra min side.
Er det mulig å forutsi utviklingen av filsystemer for de neste fem til ti årene? Hva tror du er hovedutfordringene som FS-utviklere kan møte?
Ja, det er ikke vanskelig å lage en slik prognose. Det har ikke vært utvikling av filsystemer i oppstrøms på lenge. Bare utseendet til slike skapes. Utviklere av lokale filsystemer fikk problemer knyttet til dårlig design. Her må det tas et forbehold. Jeg anser ikke såkalt "lagring", "slikking" og portering av kode som utvikling og utvikling. Og jeg klassifiserer ikke misforståelsen kalt "Btrfs" som en utvikling av de grunnene jeg allerede har forklart.
Hver patch gjør bare problemene verre. Vi vil. og det er alltid forskjellige typer "evangelister" for hvem "alt fungerer." I utgangspunktet er dette skoleelever og studenter som hopper over forelesninger. Tenk deg: det fungerer for ham, men professoren gjør det ikke. For et adrenalinkick dette er! Fra mitt synspunkt er den største skaden forårsaket av "håndverkerne" som skyndte seg å entusiastisk "skru" de fantastiske funksjonene til Btrfs på alle slags lag som systemd, docker, etc. - dette ligner allerede metastaser.
La oss nå prøve å lage en prognose for fem til ti år. Jeg har allerede kort listet opp hva vi skal gjøre i Reiser4. Hovedutfordringen for lokale FS-utviklere oppstrøms vil være (ja, det har det allerede blitt) manglende evne til å gjøre en anstendig jobb mot lønn. Uten noen ideer innen datalagring, vil de fortsette å prøve å lappe disse uheldige VFS, XFS og ext4. Situasjonen med VFS ser spesielt komisk ut på denne bakgrunn, og minner om den frenetiske moderniseringen av en restaurant der det ikke er kokker, og det ikke forventes kokker.
Nå låser VFS-koden, uten noen betingelser, flere minnesider samtidig og inviterer den underliggende FS til å operere på dem. Dette ble introdusert for å forbedre Ext4s ytelse på sletteoperasjoner, men som det er lett å forstå, er slik samtidig låsing fullstendig uforenlig med avanserte transaksjonsmodeller. Det vil si at du ikke bare kan legge til støtte for et smart filsystem i kjernen. Jeg vet ikke hvordan situasjonen er i andre områder av Linux, men når det gjelder filsystemer, er det usannsynlig at enhver utvikling her vil være forenlig med politikken Torvalds fører i praksis (akademiske prosjekter blir kastet ut, og svindlere som har ingen anelse om hva et B-tre, endeløse kreditter av tillit er utstedt). Derfor ble det satt kurs for sakte forfall. Selvfølgelig vil de prøve med all sin makt å framstille det som «utvikling».
Videre vil "vokterne" av filsystemer, som innser at du ikke vil tjene mye på "lagring" alene, prøve seg på en mer lønnsom virksomhet. Dette er som regel distribuerte filsystemer og virtualisering. Kanskje de vil portere den fasjonable ZFS et annet sted der den ikke eksisterer ennå. Men det, som alle FS fra oppstrøms, ligner et nyttårstre: hvis du kan henge noen andre små ting på toppen, kan du ikke komme dypere. Jeg innrømmer at det er mulig å bygge et seriøst bedriftssystem basert på ZFS, men siden vi nå diskuterer fremtiden, kan jeg dessverre bare konstatere at ZFS er håpløs i denne forbindelse: med sine virtuelle enheter har gutta kuttet av oksygenet for seg selv og fremtidige generasjoner for videre utvikling. ZFS er en saga blott. Og ext4 og XFS er ikke engang i forgårs.
Det er verdt å nevne separat om det oppsiktsvekkende konseptet "Linux-filsystem for neste generasjon". Dette er et fullstendig politisk og markedsføringsprosjekt laget for muligheten, så å si, til å "feste fremtiden til filsystemer" i Linux bak spesifikke karakterer. Faktum er at Linux pleide å være "bare for moro skyld". Men nå er det først og fremst en pengemaskin. De er laget på alt mulig. For eksempel er det veldig vanskelig å lage et godt programvareprodukt, men smarte "utviklere" har lenge innsett at det ikke er nødvendig å anstrenge seg i det hele tatt: du kan lykkes med å selge ikke-eksisterende programvare som ble annonsert og promotert hos alle slags offentlige hendelser - det viktigste er at presentasjonslysbildene skal inneholde flere "funksjoner".
Filsystemer er perfekte for dette, for du kan trygt prute i ti år på resultatet. Vel, hvis noen senere klager over mangelen på nettopp dette resultatet, så forstår han rett og slett ikke noe om filsystemer! Dette minner om en finanspyramide: på toppen er eventyrerne som startet dette rotet, og de få som var "heldige": de "tok ut utbytte", dvs. fått penger til utvikling, fått en godt betalt jobb som ledere, «møtte opp» på konferanser m.m.
Deretter kommer de som er "uheldige": de vil telle tap, håndtere konsekvensene av å distribuere et ubrukelig programvareprodukt i produksjon, "osv. Det er mange flere av dem. Vel, ved bunnen av pyramiden er det en enorm masse utviklere som "sager" ubrukelig kode. De er de største taperne, fordi bortkastet tid ikke kan returneres. Slike pyramider er ekstremt gunstige for Torvalds og hans medarbeidere. Og jo flere av disse pyramidene, jo bedre for dem. For å mate slike pyramider kan alt tas inn i kjernen. Selvfølgelig sier de det motsatte i offentligheten. Men jeg dømmer ikke etter ord, men etter handlinger.
Så, "fremtiden til filsystemer i Linux" er nok en høyt promotert, men knapt brukbar programvare. Etter Btrfs, med høy sannsynlighet, vil plassen til en slik "fremtid" bli tatt av Bcachefs, som er nok et forsøk på å krysse Linux-blokklaget med et filsystem (et dårlig eksempel er smittsomt). Og det som er typisk: det er de samme problemene som i Btrfs. Jeg mistenkte dette lenge, og så kunne jeg på en eller annen måte ikke motstå og så på koden - det er sant!
Forfatterne av Bcachefs og Btrfs brukte aktivt andres kilder når de opprettet sin FS, og forsto lite om dem. Situasjonen minner mye om barnespillet «ødelagt telefon». Og jeg kan omtrent forestille meg hvordan denne koden vil bli inkludert i kjernen. Faktisk vil ingen se "rakene" (alle vil tråkke på dem senere). Etter mange uenigheter om stilen til koden, anklager om ikke-eksisterende brudd, etc., vil en konklusjon bli gjort om forfatterens "lojalitet", hvor godt han "samhandler" med andre utviklere, og hvor vellykket alt dette kan deretter selges til selskaper.
Sluttresultatet vil ikke interessere noen. For tjue år siden ville jeg kanskje vært interessert, men nå stilles spørsmålene annerledes: Vil det være mulig å fremme dette slik at enkelte personer blir ansatt innen de neste ti årene. Og dessverre er det ikke vanlig å lure på sluttresultatet.
Generelt vil jeg sterkt fraråde å begynne å gjenoppfinne filsystemet fra bunnen av. For selv betydelige økonomiske investeringer vil ikke være nok til å få noe konkurransedyktig om ti år. Selvfølgelig snakker jeg om seriøse prosjekter, og ikke om de som er ment å bli "dyttet" inn i kjernen. Så en mer effektiv måte å uttrykke deg på er å bli med i virkelige utviklinger, som oss. Dette er selvfølgelig ikke lett å gjøre - men dette er tilfellet med ethvert prosjekt på høyt nivå.
Først må du selvstendig overvinne problemet jeg vil tilby. Etter det, overbevist om alvoret i intensjonene dine, vil jeg begynne å hjelpe. Tradisjonelt bruker vi kun våre egne utviklinger. Unntakene er komprimeringsalgoritmer og noen hashfunksjoner. Vi sender ikke utviklere for å reise på konferanser, og da sitter vi ikke og kombinerer andres ideer ("kanskje hva som vil skje"), slik det er vanlig i de fleste startups.
Vi utvikler alle algoritmer selv. Jeg er for tiden interessert i de algebraiske og kombinatoriske aspektene ved datalagringsvitenskap. Spesielt begrensede felt, asymptotikk, bevis på ulikheter. Det er også arbeid for vanlige programmerere, men jeg må advare deg med en gang: alle forslag om å "se på en annen FS og gjøre det samme" blir ignorert. Patcher rettet mot tettere integrasjon med Linux via VFS vil også gå dit.
Så vi har ingen rake, men vi har forståelse for hvor vi må bevege oss, og vi har tillit til at denne retningen er den rette. Denne forståelsen kom ikke i form av manna fra himmelen. La meg minne deg på at vi har 29 års utviklingserfaring bak oss, to filsystemer skrevet fra bunnen av. Og samme antall datagjenopprettingsverktøy. Og dette er mye!
Kilde: opennet.ru