Andra intervjun med Eduard Shishkin, utvecklare av Reiser4 FS

Den andra intervjun med Eduard Shishkin, utvecklare av filsystemet Reiser4, har publicerats.

Till att börja med, påminn läsarna om var och vem du arbetar för.

Jag arbetar som huvudlagringsarkitekt på Huawei Technologies, German Research Center. På virtualiseringsavdelningen arbetar jag med olika aspekter av datalagring. Mina aktiviteter är inte relaterade till ett specifikt operativsystem.

Förbinder du dig för närvarande till huvudkärngrenen?

Mycket sällan, och bara om min arbetsgivare kräver det. Förra gången var för ungefär tre år sedan skickade jag patchar för att öka genomströmningen för lagring som delas på värdar med hjälp av 9p-protokollet (ett annat namn för den här verksamheten är VirtFS). En viktig anmärkning måste göras här: även om jag har arbetat med Linux länge, har jag aldrig varit ett fan av det, det vill säga jag "andas jämnt", som med allt annat. I synnerhet om jag märker en brist kan jag påpeka den högst en gång. Och så att du sedan kan följa någon och övertala dem – det här kommer inte att hända.

Jag minns förra gången, för tio år sedan, du var ganska kritisk till kärnans utvecklingsstil. Ur din (eller kanske företagets) synvinkel, har något förändrats, har samhället blivit mer lyhört eller inte? Om inte, vem tror du är skyldig?

Jag har aldrig sett några förändringar till det bättre. Gemenskapens huvudproblem är att ersätta vetenskap med politisk teknologi, personliga relationer, majoritetsopinioner, populism, råd från "inre röster", ruttna kompromisser, allt annat än vetenskap. Datavetenskap, vad man än kan säga, är först och främst en exakt vetenskap. Och om någon börjar proklamera sitt eget värde för 2x2, annorlunda än 4, under "Linux way"-flaggan, eller under någon annan flagga, är det osannolikt att detta kommer att orsaka något annat än skada.

Alla problem beror i första hand på inkompetens och bristande utbildning hos de som fattar beslut. Om en chef är inkompetent kan han inte fatta ett objektivt, adekvat beslut. Om han också är okultiv, kan han inte hitta en kompetent specialist som kommer att ge honom rätt råd. Med stor sannolikhet kommer valet att falla på en bedragare som säger "till synes korrekta saker." En korrupt miljö utvecklas alltid kring inkompetenta ensamma ledare. Historien känner dessutom inga undantag i detta avseende, och samhället är den tydligaste bekräftelsen på detta.

Hur bedömer du framstegen i Btrfs utveckling? Blev denna FS av med barnsjukdomar? Hur positionerar du det för dig själv - som en FS "för hemmet" eller för företagsbruk också?

Jag blev inte av med det. Allt som jag nämnde för 11 år sedan är fortfarande relevant idag. Ett av problemen med Btrfs som gör den olämplig för allvarliga behov är problemet med ledigt utrymme. Jag pratar inte ens om det faktum att användaren uppmanas att springa till butiken för en ny disk i situationer där någon annan FS skulle visa mycket ledigt utrymme på partitionen. Oförmågan att genomföra en operation på en logisk volym på grund av brist på ledigt utrymme är inte heller det värsta. Det värsta är att en oprivilegierad användare nästan alltid kan, kringgå eventuella diskkvoter, beröva alla ledigt utrymme på ganska kort tid.

Det ser ut så här (testat för Linuxkärna 5.12). Ett script lanseras på ett nyinstallerat system, som i en slinga skapar filer med vissa namn i hemkatalogen, skriver data till dem med vissa förskjutningar och sedan raderar dessa filer. Efter en minuts körning av det här skriptet händer inget ovanligt. Efter fem minuter ökar andelen upptaget utrymme på partitionen något. Efter två till tre timmar når den 50 % (med ett initialt värde på 15 %). Och efter fem eller sex timmars arbete kraschar skriptet med felet "det finns inget ledigt utrymme på partitionen." Efter detta kan du inte längre skriva ens en 4K-fil till din partition.

En intressant situation uppstår: det slutade med att du inte skrev något till partitionen, och allt ledigt utrymme (cirka 85%) försvann någonstans. Analys av en sektion som är föremål för en sådan attack kommer att avslöja många trädnoder som bara innehåller ett objekt (ett objekt utrustat med en nyckel), flera byte i storlek. Det vill säga innehållet som tidigare upptog 15% av diskutrymmet visade sig vara jämnt "smetat" över hela partitionen så att det inte finns någonstans att skriva en ny fil, eftersom dess nyckel är större än alla befintliga, och den fria blocken på partitionen har tagit slut.

Dessutom sker allt detta redan på den grundläggande Btrfs-konfigurationen (utan några ögonblicksbilder, undervolymer, etc.), och det spelar ingen roll hur du bestämmer dig för att lagra filkroppar i den FS (som "fragment" i ett träd eller som omfattningar av oformaterade block) - slutresultatet blir detsamma.

Du kommer inte att kunna utsätta andra uppströms filsystem för en sådan attack (oavsett vad de säger till dig). Jag förklarade orsaken till problemet för länge sedan: detta är en fullständig perversion av B-tree-konceptet i Btrfs, vilket gör det möjligt för det att spontant eller avsiktligt degenerera. I synnerhet under vissa belastningar kommer ditt filsystem kontinuerligt att "falla isär" under drift på egen hand, utan hjälp utifrån. Det är tydligt att alla typer av "tryckande" bakgrundsprocesser kommer att rädda dagen bara på enskilda skrivbord.

På kollektiva servrar kommer en angripare alltid att kunna "komma före" dem. Systemadministratören kommer inte ens att kunna avgöra vem som exakt mobbade honom. Det snabbaste sättet att fixa detta problem i Btrfs är att återställa strukturen hos ett vanligt B-träd, d.v.s. designa om skivformatet och skriva om betydande delar av Btrfs-koden. Detta kommer att ta 8-10 år, inklusive felsökning, förutsatt att utvecklarna strikt följt de ursprungliga artiklarna om relevanta algoritmer och datastrukturer och inte spelade spelet "trasig telefon", som är vanligt (och uppmuntras) i "Linux" sätt".

Här behöver vi också lägga till den tid som krävs för att utvecklare ska förstå allt detta. Det är här det blir svårare. 10 år räckte i alla fall inte för att de skulle förstå. Tja, tills dess kan du inte hoppas på ett mirakel. Det kommer inte att hända i form av ett monteringsalternativ "som du och jag inte visste om", eller i form av en lapp som "bara är en affärsfråga" att förbereda. För varje sådan hastig "fix" kommer jag att presentera ett nytt scenario av degeneration. B-träd är ett av mina favoritämnen, och jag måste säga att dessa strukturer inte tolererar friheter med sig själva!

Hur placerar jag Btrfs för mig själv? Som något som absolut inte kan kallas ett filsystem, än mindre användas. Eftersom FS per definition är ett OS-undersystem som ansvarar för effektiv hantering av "diskutrymmes"-resursen, vilket vi inte ser i fallet med Btrfs. Tja, föreställ dig att du kom till butiken för att köpa en klocka för att inte komma för sent till jobbet, och istället för en klocka sålde de dig en elektrisk grill med timer i max 30 minuter. Så situationen med Btrfs är ännu värre.

När jag tittar igenom e-postlistor stöter jag ofta på påståendet att effektiv hantering av diskutrymme inte längre är relevant på grund av de billiga enheterna. Detta är fullständigt nonsens. Utan en effektiv diskutrymmeshanterare kommer operativsystemet att bli sårbart och oanvändbart. Oavsett kapaciteten på diskarna på din maskin.

Jag skulle vilja be om en kommentar om upphörandet av Btrfs-stöd i RHEL.

Det finns inget speciellt att kommentera här, allt är väldigt tydligt. De hade det också som en "teknikförhandstitt". Så jag gick inte igenom denna mycket "förhandsvisning". Låt inte denna etikett hänga för evigt! Men de kan inte lansera en felaktig bydesign-produkt med fullt stöd. RHEL är ett företag, det vill säga föreskrivna varu-pengarrelationer. Red Hat kan inte mobba användare som de gör på Btrfs e-postlista. Föreställ dig bara situationen: en klient som betalade sina surt förvärvade pengar för disken och även du för support, vill förstå var hans diskutrymme tog vägen efter att han inte skrivit ner något. Vad kommer du att svara honom på detta?

Ytterligare. Bland Red Hats kunder finns välkända storbanker och börser. Föreställ dig vad som skulle hända om de utsattes för DoS-attacker baserat på den nämnda sårbarheten i Btrfs. Vem tror du är ansvarig för detta? Till de som är på väg att peka finger på raden i GPL-licensen, där det står skrivet att författaren inte är ansvarig för någonting, kommer jag genast att säga: "gömma bort det!" Red Hat kommer att svara, och på ett sådant sätt att det inte verkar tillräckligt! Men jag vet att Red Hat inte står inför den här typen av problem, med tanke på deras särskilt starka team av QA-ingenjörer som jag hade möjlighet att arbeta nära under min tid.

Varför fortsätter vissa företag att stödja Btrfs i sina företagsprodukter?

Observera att prefixet "företag" i produktnamnet inte betyder mycket. Enterprise är ett mått på ansvar som är inbäddat i avtalsförhållandet med kunden. Jag känner bara till ett företag baserat på GNU/Linux - RHEL. Allt annat, ur min synvinkel, presenteras bara som ett företag, men är inte ett. Och slutligen, om det finns en efterfrågan på något, kommer det alltid att finnas ett utbud (i vårt fall är detta det nämnda "stödet"). Det finns efterfrågan på absolut allt, inkl. och oanvändbar programvara. Hur en sådan efterfrågan bildas och vem som driver den är ett annat ämne.

Så jag skulle inte dra några slutsatser efter att Facebook ryktas ha distribuerat Btrfs på sina servrar. Dessutom skulle jag rekommendera att noggrant hålla adresserna till dessa servrar hemliga av ovanstående skäl.

Varför har så mycket ansträngning lagts på att rensa upp XFS-koden på sistone? Till en början är det här ett filsystem från tredje part, och ext4 har varit stabilt under lång tid och har kontinuitet från tidigare lika stabila versioner. Vilket intresse har Red Hat för XFS? Är det vettigt att aktivt utveckla två filsystem som har liknande syfte - ext4 och XFS?

Jag minns inte vad som motiverade detta. Det är mycket möjligt att initiativet kom från Red Hat-kunder. Jag minns att forskning av det här slaget utfördes: på vissa filsystem uppströms skapades ett gigantiskt antal objekt på avancerade enheter av den nya generationen. Enligt resultaten betedde sig XFS bättre än ext4. Så de började marknadsföra det som det mest lovande. Jag skulle i alla fall inte leta efter något sensationellt här.

För mig är det som att de har ersatt en syl med tvål. Det är ingen idé att utveckla ext4 och XFS. Både parallellt och någon av dem att välja mellan. Inget gott kommer att komma av detta. Även i naturen finns det ofta situationer när det finns mycket potential för tillväxt, men det finns inget utrymme att växa. I det här fallet uppstår olika bisarrt fula nya tillväxter, som alla pekar på ("Åh, titta, vad du inte kommer att se i det här livet!").

Tror du att frågan om lageröverträdelse har lösts (i negativ bemärkelse) med tillkomsten av krypteringsfunktioner i ext4, F2FS (för att inte tala om RAID i Btrfs)?

Generellt sett är införandet av alla nivåer och att fatta beslut om att de inte kränks, vanligtvis en fråga om policy, och jag åtar mig inte att kommentera någonting här. De objektiva aspekterna av lageröverträdelse är av lite intresse för någon, men vi kan överväga några av dem med exemplet på överträdelse "från ovan", nämligen implementeringen i FS av funktionalitet som redan finns på blocklagret. En sådan "kränkning" är motiverad med endast sällsynta undantag. För varje sådant fall måste du först bevisa två saker: att det verkligen behövs, och att utformningen av systemet inte kommer att skadas av att göra det.

Till exempel är spegling, som traditionellt har varit en aktivitet för blocklagret, vettigt att implementera på filsystemnivå. Av olika anledningar. Till exempel inträffar "tyst" datakorruption (bitröta) på hårddiskar. Detta är när enheten fungerar korrekt, men blockdatan oväntat skadas under påverkan av ett hårt gammakvantum som emitteras av en avlägsen kvasar, etc. Det värsta är om det här blocket visar sig vara ett FS-systemblock (superblock, bitmappsblock, lagringsträdsnod, etc.), eftersom detta säkerligen kommer att leda till kärnpanik.

Observera att speglarna som erbjuds av blocklagret (så kallad RAID 1) inte kommer att rädda dig från detta problem. Nåväl, verkligen: någon borde kontrollera kontrollsummorna och läsa repliken i händelse av misslyckande? Dessutom är det vettigt att spegla inte bara allt, utan bara metadata. Vissa viktiga data (till exempel körbara filer för kritiska applikationer) kan lagras som metadata. I det här fallet får de samma säkerhetsgarantier. Det är vettigt att anförtro skyddet av återstående data till andra delsystem (kanske till och med användarapplikationer) - vi har tillhandahållit alla nödvändiga villkor för detta.

Sådana "ekonomiska" speglar har rätt att existera, och de kan bara organiseras effektivt på filsystemsnivå. Annars är lagöverträdelser att belamra ett delsystem med duplicerad kod för vissa mikroskopiska fördelar. Ett slående exempel på detta är implementeringen av RAID-5 med FS. Sådana lösningar (egen RAID / LVM i filsystemet) dödar det senare i arkitektoniska termer. Det bör också noteras här att lageröverträdelser "sätts i drift" av olika typer av marknadsföringsbedragare. I avsaknad av några idéer läggs funktionalitet som länge har implementerats på angränsande nivåer till undersystemen, detta presenteras som en ny extremt användbar funktion och drivs aktivt.

Reiser4 anklagades för att ha brutit mot nivåerna "underifrån". Baserat på att filsystemet inte är monolitiskt, som alla andra, utan modulärt, gjordes ett ogrundat antagande att det gör vad nivån ovan (VFS) ska göra.

Är det möjligt att tala om döden av ReiserFS v3.6 och till exempel JFS? Den senaste tiden har de nästan inte fått någon uppmärksamhet i kärnan. Är de föråldrade?

Här måste vi definiera vad en mjukvaruprodukts död betyder. Å ena sidan används de framgångsrikt (det är trots allt vad de skapades för), vilket betyder att de lever. Å andra sidan kan jag inte tala för JFS (jag vet inte så mycket), men ReiserFS (v3) är väldigt svår att anpassa till nya trender (testat i praktiken). Detta innebär att utvecklare i framtiden inte kommer att uppmärksamma det, utan till de som är lättare att anpassa. Från denna sida visar det sig att den tyvärr är död i arkitektoniskt hänseende. Jag skulle inte alls manipulera begreppet "moraliskt föråldrat". Det gäller till exempel bra för en garderob, men inte för mjukvaruprodukter. Det finns ett begrepp om underlägsenhet och överlägsenhet i något. Jag kan absolut säga att ReserFS v3 nu är sämre än Reiser4 i allt, men i vissa typer av arbetsbelastning är den överlägsen alla andra uppströms FS:er.

Känner du till utvecklingen av FS Tux3 och HAMMER/HAMMER2 (FS för DragonFly BSD)?

Ja, vi vet. I Tux3 var jag en gång intresserad av tekniken för deras ögonblicksbilder (de så kallade "versionspekarna"), men i Reiser4 kommer vi med största sannolikhet att gå en annan väg. Jag har länge funderat på att stödja ögonblicksbilder och har ännu inte bestämt mig för hur jag ska implementera dem för enkla Reiser4-volymer. Faktum är att den nymodiga "lata" referensräknartekniken som föreslagits av Ohad Rodeh bara fungerar för B-träd. Vi har dem inte. För de datastrukturer som används i Reiesr4 är "lata" räknare inte definierade - för att introducera dem är det nödvändigt att lösa vissa algoritmiska problem, som ingen har tagit på sig ännu.

Enligt HAMMER: Jag läste en artikel från skaparen. Inte intresserad. Återigen, B-träd. Denna datastruktur är hopplöst föråldrad. Vi övergav det under förra seklet.

Hur bedömer du den växande efterfrågan på nätverkskluster-FS:er som CephFS/GlusterFS/etc? Innebär detta krav en förändring av utvecklarnas prioriteringar mot nätverks-FS och otillräcklig uppmärksamhet på lokal FS?

Ja, en sådan förändring av prioriteringarna har skett. Utvecklingen av lokala filsystem har stagnerat. Tyvärr, att göra något betydande för lokala volymer är nu ganska svårt och inte alla kan göra det. Ingen vill satsa på sin utveckling. Det är ungefär detsamma som att be en kommersiell organisation att anslå pengar till matematisk forskning – utan någon entusiasm kommer de att fråga dig hur du kan tjäna pengar på ett nytt teorem. Nu är en lokal FS något som magiskt framstår som "utanför lådan" och "bör alltid fungera", och om det inte fungerar, orsakar det oadresserat gnäll som: "Ja, vad tänker de!"

Därav bristen på uppmärksamhet till lokala FS, även om det fortfarande finns mycket arbete på det området. Och ja, alla har vänt sig till distribuerad lagring, som bygger på redan befintliga lokala filsystem. Det är väldigt på modet nu. Frasen "Big Data" orsakar en adrenalinkick för många, associerar den med konferenser, workshops, höga löner etc.

Hur rimligt är det i princip att implementera nätverksfilsystemet i kärnutrymme snarare än i användarutrymme?

Ett mycket rimligt tillvägagångssätt som ännu inte har implementerats någonstans. I allmänhet är frågan om i vilket utrymme ett nätverksfilsystem ska implementeras ett "tveeggat svärd." Tja, låt oss titta på ett exempel. Klienten registrerade data på en fjärrmaskin. De föll in i hennes sidcache i form av smutsiga sidor. Detta är jobbet för ett "tunn gateway" nätverksfilsystem i kärnutrymme. Då kommer operativsystemet förr eller senare att be dig att skriva dessa sidor till disken för att frigöra dem. Då kommer IO-vidarebefordran (sändande) nätverks FS-modulen in i bilden. Det bestämmer vilken servermaskin (servernod) dessa sidor ska gå till.

Sedan tar nätverksstacken över (och som vi vet är den implementerad i kärnutrymmet). Därefter tar servernoden emot det paketet med data eller metadata och instruerar backend-lagringsmodulen (d.v.s. den lokala FS som arbetar i kärnutrymmet) att spela in allt det här. Så vi har reducerat frågan till var modulerna "sändande" och "mottagande" ska fungera. Om någon av dessa moduler körs i användarutrymmet kommer detta oundvikligen att leda till kontextbyte (på grund av behovet av att använda kärntjänster). Antalet sådana switchar beror på implementeringsdetaljerna.

Om det finns många sådana switchar kommer lagringskapaciteten (I/O-prestanda) att minska. Om din backend-lagring består av långsamma diskar, kommer du inte att märka en betydande nedgång. Men om du har snabba diskar (SSD, NVRAM, etc.) blir kontextväxling redan en "flaskhals" och genom att spara på kontextväxling kan prestandan ökas avsevärt. Det vanliga sättet att spara pengar är att flytta moduler till kärnutrymmet. Till exempel fann vi att flytta 9p-servern från QEMU till kärnan på värddatorn leder till en trefaldig ökning av VirtFS-prestanda.

Detta är naturligtvis inte ett nätverk FS, men det återspeglar till fullo essensen av saker och ting. Nackdelen med denna optimering är portabilitetsproblem. För vissa kan det senare vara kritiskt. Till exempel har GlusterFS inga moduler i kärnan alls. Tack vare detta fungerar det nu på många plattformar, inklusive NetBSD.

Vilka koncept kan lokala FS:er låna från nätverksföretag och vice versa?

Nuförtiden har nätverks-FS som regel tillägg över lokala FS, så jag förstår inte riktigt hur du kan låna något från de senare. Tja, faktiskt, låt oss överväga ett företag med 4 anställda, där alla gör sin egen grej: en distribuerar, en annan skickar, den tredje tar emot, den fjärde butiker. Och frågan, vad kan företaget låna av sin anställd som lagrar det, låter på något sätt felaktig (det har redan haft vad det kunde ha lånat av honom under lång tid).

Men lokala FS:er har mycket att lära av nätverk. För det första bör du lära dig av dem hur man aggregerar logiska volymer på en hög nivå. Nu den sk "avancerade" lokala filsystem samlar logiska volymer uteslutande med hjälp av "virtuell enhet"-teknik lånad från LVM (samma infektiösa lageröverträdelse som först implementerades i ZFS). Med andra ord, översättning av virtuella adresser (blocknummer) till riktiga och tillbaka sker på en låg nivå (dvs efter att filsystemet har utfärdat en I/O-begäran).

Observera att att lägga till och ta bort enheter till logiska volymer (inte speglar) anordnade på blocklagret leder till problem som leverantörer av sådana "funktioner" är blygsamt tysta om. Jag pratar om fragmentering på riktiga enheter, som kan nå monstruösa värden, medan på en virtuell enhet är allt bra. Men få människor är intresserade av virtuella enheter: alla är intresserade av vad som händer på dina riktiga enheter. Men ZFS-liknande FS (liksom alla FS i samband med LVM) fungerar bara med virtuella diskenheter (tilldela virtuella diskadresser bland lediga, defragmentera dessa virtuella enheter, etc.). Och de har ingen aning om vad som händer på riktiga enheter!

Föreställ dig nu att du har noll fragmentering på den virtuella enheten (det vill säga du har bara en gigantisk omfattning som bor där), du lägger till en disk till din logiska volym och tar sedan bort en annan slumpmässig disk från din logiska volym och balanserar sedan om. Och så många gånger. Det är inte svårt att föreställa sig att på den virtuella enheten kommer du fortfarande att leva i samma utsträckning, men på riktiga enheter kommer du inte att se något bra.

Det värsta är att du inte ens kan rätta till den här situationen! Det enda du kan göra här är att be filsystemet att defragmentera den virtuella enheten. Men hon kommer att berätta att allt är bra där - det finns bara en omfattning, fragmenteringen är noll, och det kan inte bli bättre! Så logiska volymer arrangerade på blocknivå är inte avsedda för upprepad tillägg/borttagning av enheter. På ett bra sätt behöver du bara sätta ihop en logisk volym på blocknivå en gång, ge den till filsystemet och sedan inte göra något annat med den.

Dessutom tillåter kombinationen av oberoende FS+LVM-undersystem inte att ta hänsyn till de olika egenskaperna hos de enheter från vilka logiska volymer aggregeras. Anta faktiskt att du har satt ihop en logisk volym från hårddisken och solid-state-enheter. Men då kommer det förra att kräva defragmentering, och det senare inte. För den senare måste du utfärda begäranden om att kassera, men för den förra, inte, etc. I denna kombination är det emellertid ganska svårt att visa sådan selektivitet.

Observera att efter att ha skapat din egen LVM på filsystemet blir situationen inte mycket bättre. Dessutom, genom att göra detta sätter du faktiskt stopp för möjligheten att någonsin förbättra det i framtiden. Det här är väldigt dåligt. Olika typer av enheter kan leva på samma maskin. Och om filsystemet inte skiljer mellan dem, vem gör det då?

Ett annat problem ligger och väntar på den sk. "Write-Anywhere" filsystem (detta inkluderar även Reiser4, om du angav lämplig transaktionsmodell under monteringen). Sådana filsystem måste tillhandahålla defragmenteringsverktyg som saknar motstycke i sin makt. Och volymhanteraren på låg nivå hjälper inte här, utan kommer bara i vägen. Faktum är att med en sådan hanterare kommer din FS att lagra en karta över fria block av endast en enhet - en virtuell. Följaktligen kan du bara defragmentera en virtuell enhet. Detta innebär att din defragmenterare kommer att fungera under lång, lång tid på ett stort enda utrymme av virtuella adresser.

Och om du har många användare som gör slumpmässiga överskrivningar, kommer den användbara effekten av en sådan defragmenterare att reduceras till noll. Ditt system kommer oundvikligen att börja sakta ner, och du behöver bara lägga händerna inför den nedslående diagnosen "trasig design". Flera defragmenterare som körs på samma adressutrymme kommer bara att störa varandra. Det är en helt annan sak om du underhåller din egen karta över gratisblock för varje riktig enhet. Detta kommer effektivt att parallellisera defragmenteringsprocessen.

Men detta kan bara göras om du har en logisk volymhanterare på hög nivå. Lokala filsystem med sådana hanterare fanns inte tidigare (åtminstone jag vet inte om dem). Endast nätverksfilsystem (till exempel GlusterFS) hade sådana hanterare. Ett annat mycket viktigt exempel är verktyget volymintegritetskontroll (fsck). Om du lagrar din egen oberoende karta över fria block för varje delvolym, kan proceduren för att kontrollera en logisk volym effektivt parallelliseras. Med andra ord, logiska volymer med chefer på hög nivå skalar bättre.

Dessutom, med volymhanterare på låg nivå kommer du inte att kunna organisera fullfjädrade ögonblicksbilder. Med LVM- och ZFS-liknande filsystem kan du bara ta lokala ögonblicksbilder, men inte globala ögonblicksbilder. Lokala ögonblicksbilder låter dig omedelbart återställa endast vanliga filoperationer. Och ingen där kommer att återställa operationer med logiska volymer (lägga till/ta bort enheter). Låt oss titta på detta med ett exempel. Vid någon tidpunkt, när du har en logisk volym av två enheter A och B som innehåller 100 filer, tar du en ögonblicksbild av system S och skapar sedan ytterligare hundra filer.

Efter det lägger du till enhet C till din volym och återställer slutligen ditt system till ögonblicksbild S. Fråga: Hur många filer och enheter innehåller din logiska volym efter återställning till S? Det kommer att finnas 100 filer, som du kanske har gissat, men det kommer att finnas 3 enheter - det här är samma enheter A, B och C, även om när ögonblicksbilden skapades fanns det bara två enheter i systemet (A och B ). Åtgärden för att lägga till enhet C gick inte tillbaka, och om du nu tar bort enhet C från datorn kommer det att förstöra dina data, så innan du raderar måste du först utföra en dyr operation för att ta bort enheten från den logiska ombalanseringsvolymen, vilket kommer att sprida all data från enhet C till enheter A och B. Men om din FS stödde globala ögonblicksbilder skulle sådan ombalansering inte krävas, och efter en omedelbar återställning till S kan du säkert ta bort enhet C från datorn.

Så, globala ögonblicksbilder är bra eftersom de tillåter dig att undvika den kostsamma borttagningen (tillägget) av en enhet från en logisk volym (till en logisk volym) med en stor mängd data (naturligtvis, om du kommer ihåg att "snapshot" ditt system vid rätt tillfälle). Låt mig påminna dig om att skapa ögonblicksbilder och rulla tillbaka filsystemet till dem är omedelbara operationer. Frågan kan uppstå: hur är det ens möjligt att omedelbart rulla tillbaka en operation på en logisk volym som tog dig tre dagar? Men det är möjligt! Förutsatt att ditt filsystem är korrekt utformat. Jag kom på idén med sådana "3D-ögonblicksbilder" för tre år sedan, och förra året patenterade jag den här tekniken.

Nästa sak som lokala FS:er bör lära sig av nätverks sådana är att lagra metadata på separata enheter på samma sätt som nätverks FS:er lagrar dem på separata maskiner (de så kallade metadataservrarna). Det finns applikationer som i första hand arbetar med metadata, och dessa applikationer kan accelereras kraftigt genom att placera metadata på dyra högpresterande lagringsenheter. Med kombinationen FS+LVM kommer du inte att kunna visa sådan selektivitet: LVM vet inte vad som finns på blocket som du skickade till det (data där eller metadata).

Du kommer inte att få mycket nytta av att implementera din egen lågnivå-LVM i FS jämfört med FS+LVM-kombinationen, men det du kan göra mycket bra är att röra ner FS så att det senare blir omöjligt att arbeta med dess kod. ZFS och Btrfs, som rusade med virtuella enheter, är alla tydliga exempel på hur lageröverträdelser dödar systemet i arkitektoniska termer.Så varför är jag allt detta? Dessutom finns det inget behov av att installera din egen lågnivå-LVM i filsystemet. Istället måste du aggregera enheter till logiska volymer på en hög nivå, vilket vissa nätverksfilsystem gör med olika maskiner (lagringsnoder). Det är sant att de gör detta äckligt på grund av användningen av dåliga algoritmer.

Exempel på helt fruktansvärda algoritmer är DHT-översättaren i filsystemet GlusterFS och den så kallade CRUSH-kartan i filsystemet Ceph. Ingen av de algoritmer som jag såg tillfredsställde mig vad gäller enkelhet och god skalbarhet. Så jag var tvungen att komma ihåg algebra och hitta på allt själv. 2015, medan jag experimenterade med buntar över hash-funktioner, kom jag på och patenterade något som passar mig. Nu kan jag säga att försöket att omsätta allt detta i praktiken var framgångsrikt. Jag ser inga problem med skalbarhet i det nya tillvägagångssättet.

Ja, varje undervolym kommer att kräva en separat struktur som ett superblock i minnet. Är det här väldigt skrämmande? I allmänhet vet jag inte vem som kommer att "koka havet" och skapa logiska volymer av hundratusentals eller fler enheter på en lokal maskin. Om någon kan förklara detta för mig är jag mycket tacksam. Under tiden är det här marknadsföringssnack för mig.

Hur påverkade ändringar i kärnblocksenhetsundersystemet (till exempel utseendet på blk-mq) kraven för FS-implementering?

De hade ingen inverkan. Jag vet inte vad som skulle hända på blocklagret som skulle göra det nödvändigt att designa en ny FS. Interaktionsgränssnittet för dessa delsystem är mycket dåligt. Från förarsidan bör FS bara påverkas av utseendet på nya typer av enheter, till vilka blockskiktet kommer att justeras först, och sedan FS (för reiser4 innebär detta utseendet av nya plugins).

Betyder uppkomsten av nya typer av media (till exempel SMR eller SSD-enheternas allestädes närvarande) i grunden nya utmaningar för filsystemdesign?

Ja. Och dessa är normala incitament för utvecklingen av FS. Utmaningar kan vara olika och helt oväntade. Till exempel har jag hört talas om enheter där hastigheten på en I/O-operation är starkt beroende av storleken på en databit och dess offset. I Linux, där storleken på FS-blocket inte kan överstiga sidstorleken, kommer en sådan enhet inte att visa sina fulla funktioner som standard. Men om ditt filsystem är korrekt designat finns det en chans att få ut mycket mer av det.

Hur många personer arbetar för närvarande med Reiser4-koden förutom du?

Mindre än jag skulle vilja, men jag upplever inte heller akut brist på resurser. Jag är mer än nöjd med utvecklingstakten för Reiser4. Jag tänker inte "köra hästar" - det här är inte rätt område. Här, "om du kör tystare kommer du att fortsätta!" Ett modernt filsystem är det mest komplexa kärnundersystemet, vars felaktiga designbeslut kan ångra efterföljande år av mänskligt arbete.

Genom att erbjuda volontärer att genomföra något garanterar jag alltid att insatserna säkerligen leder till rätt resultat, vilket kan efterfrågas vid allvarliga behov. Som du förstår kan det inte finnas många sådana garantier på en gång. Samtidigt kan jag inte stå ut med "figurer" som skamlöst främjar "funktioner" i uppenbart oanvändbar programvara, lurar hundratals användare och utvecklare, och samtidigt sitter och ler vid kärntoppmöten.

Har något företag uttryckt sin vilja att stödja utvecklingen av Reiser4?

Ja, det fanns sådana förslag, inkl. och från en stor leverantör. Men för detta var jag tvungen att flytta till ett annat land. Tyvärr är jag inte längre 30 år gammal, jag kan inte bryta mig loss och gå därifrån vid första signalen.

Vilka funktioner saknas för närvarande i Reiser4?

Det finns ingen "ändra storlek"-funktion för enkla volymer, liknande den som finns i ReiserFS(v3). Dessutom skulle filoperationer med DIRECT_IO-flaggan inte skada. Därefter skulle jag vilja kunna dela upp en volym i "semantiska delvolymer", som inte har en fast storlek, och som kan monteras som oberoende volymer. Dessa problem är bra för nybörjare som vill prova sig fram med den "riktiga varan".

Och slutligen skulle jag vilja ha nätverkslogiska volymer med enkel implementering och administration (moderna algoritmer tillåter redan detta). Men vad Reiser4 definitivt aldrig kommer att ha är RAID-Z, scrubs, cacher för ledigt utrymme, 128-bitars variabler och annat marknadsföringssnack som uppstod mot bakgrund av en brist på idéer bland utvecklarna av vissa filsystem.

Kan allt som kan behövas implementeras av plugins?

Om vi ​​bara talar om gränssnitt och plugins (moduler) som implementerar dem, då inte allt. Men om du också introducerar relationer på dessa gränssnitt, så kommer du bland annat att ha begreppen högre polymorfismer, som du redan klarar dig med. Föreställ dig att du hypotetiskt frös ett objektorienterat runtime-system, ändrade värdet på instruktionspekaren till att peka på ett annat plugin som implementerar samma X-gränssnitt och sedan låste upp systemet så att det fortsätter att köras.

Om slutanvändaren inte märker en sådan "substitution" så säger vi att systemet har nollordningens polymorfism i X-gränssnittet (eller så är systemet heterogent i X-gränssnittet, vilket är samma sak). Om du nu inte bara har en uppsättning gränssnitt, utan också har relationer på dem (gränssnittsgraf), kan du introducera polymorfismer av högre ordning, vilket kommer att karakterisera heterogeniteten i systemet redan i "grannskapet" av vilket gränssnitt som helst. Jag införde en sådan klassificering för länge sedan, men tyvärr hände det aldrig.

Så med hjälp av plugins och sådana högre polymorfismer kan du beskriva vilken känd funktion som helst, samt "förutsäga" de som aldrig ens har nämnts. Jag har inte kunnat bevisa detta strikt, men jag känner inte heller till något motexempel ännu. I allmänhet påminde denna fråga mig om Felix Kleins "Erlangen-program". En gång försökte han representera all geometri som en gren av algebra (specifikt gruppteori).

Nu till huvudfrågan - hur går det med marknadsföringen av Reiser4 till huvudkärnan? Fanns det några publikationer om arkitekturen för detta filsystem som du pratade om i förra intervjun? Hur relevant är denna fråga ur din synvinkel?

Generellt har vi bett om inkludering i huvudgrenen i tre år. Reisers sista kommentar i den offentliga tråden där pull-begäran gjordes förblev obesvarad. Så alla ytterligare frågor är inte för oss. Jag förstår personligen inte varför vi behöver "slå ihop" till ett specifikt operativsystem. På Linux konvergerade inte ljuset som en kil. Så det finns ett separat arkiv där det kommer att finnas flera filialportar för olika operativsystem. Den som behöver det kan klona motsvarande port och göra vad du vill med den (inom licensen förstås). Tja, om någon inte behöver det, så är det inte mitt problem. Vid det här laget föreslår jag att man överväger frågan om "befordran till Linux-huvudkärnan" som avgjord.

Publikationer om FS-arkitektur är relevanta, men än så länge har jag bara hittat tid till mina nya resultat, som jag anser vara högre prioritet. En annan sak är att jag är matematiker, och i matematik är vilken publikation som helst en sammanfattning av teorem och deras bevis. Att publicera något där utan bevis är ett tecken på dålig smak. Om jag grundligt bevisar eller motbevisar något påstående om FS:s arkitektur, så blir resultatet sådana pålar att det blir ganska svårt att ta sig igenom. Vem behöver det? Det är förmodligen därför allt fortsätter att förbli i sin gamla form - källkoden och kommentarer till den.

Vad är nytt i Reiser4 under de senaste åren?

Den efterlängtade stabiliteten har äntligen materialiserats. En av de sista som dök upp var en bugg som ledde till "oborttagbara" kataloger. Svårigheten var att den endast dök upp mot bakgrund av namnhashkollisioner och med en viss plats för katalogposter i en trädnod. Men jag kan fortfarande inte rekommendera Reiser4 för produktion: för detta måste du göra en del arbete med aktiv interaktion med produktionssystemadministratörer.

Vi lyckades äntligen implementera vår mångåriga idé – olika transaktionsmodeller. Tidigare körde Reiser4 bara en hårdkodad Macdonald-Reiser-modell. Detta skapade designproblem. I synnerhet är ögonblicksbilder inte möjliga i en sådan transaktionsmodell - de kommer att skadas av en atomkomponent som kallas "OVERWRITE SET". Reiser4 stöder för närvarande tre transaktionsmodeller. I en av dem (Write-Anywhere) innehåller den atomära komponenten OVERWRITE SET endast systemsidor (bilder av skivbitmappar, etc.), som inte kan "fotograferas" (problemet med kyckling och ägg).

Så bilderna kan nu realiseras på bästa möjliga sätt. I en annan transaktionsmodell går alla modifierade sidor endast till OVERWRITE SET (det vill säga det är i huvudsak ren journalisering). Denna modell är för dem som klagade på den snabba fragmenteringen av Reiser4-partitioner. Nu i den här modellen kommer din partition inte att fragmenteras snabbare än med ReiserFS (v3). Alla tre befintliga modeller, med vissa reservationer, garanterar operationens atomicitet, men modeller med förlust av atomicitet och bevarar endast sektionens integritet kan också vara användbara. Sådana modeller kan vara användbara för alla typer av applikationer (databaser, etc.), som redan har tagit på sig några av dessa funktioner. Det är väldigt lätt att lägga till dessa modeller till Reiser4, men jag gjorde det inte, eftersom ingen frågade mig, och jag personligen behöver det inte.

Metadatakontrollsummor dök upp och jag kompletterade dem nyligen med "ekonomiska" speglar" (fortfarande instabilt material). Om kontrollsumman för något block misslyckas läser Reiser4 omedelbart motsvarande block från replikenheten. Observera att ZFS och Btrfs inte kan göra detta: designen tillåter det inte. Där måste du köra en speciell bakgrundsskanningsprocess som kallas "skrubba" och vänta på att den kommer till det problematiska blocket. Programmerare kallar bildligt sådana händelser "kryckor".

Och slutligen har heterogena logiska volymer dykt upp som erbjuder allt som ZFS, Btrfs, blocklager, såväl som FS+LVM-kombinationer i princip inte kan tillhandahålla - parallell skalning, O(1) diskadressallokator, transparent datamigrering mellan undervolymer. Den senare har också ett användargränssnitt. Nu kan du enkelt flytta den hetaste datan till den högst presterande enheten på din volym.

Dessutom är det möjligt att snabbt spola alla smutsiga sidor till en sådan enhet, och därigenom avsevärt snabba upp applikationer som ofta anropar fsync(2). Jag noterar att blocklagerfunktionaliteten, kallad bcache, inte ger sådan handlingsfrihet alls. Nya logiska volymer är baserade på mina algoritmer (det finns motsvarande patent). Mjukvaran är redan ganska stabil, det är fullt möjligt att prova det, mäta prestanda, etc. Det enda besväret är att du för närvarande måste uppdatera volymkonfigurationen manuellt och lagra den någonstans.

Hittills har jag kunnat implementera mina idéer med 10 procent, men jag har lyckats med det jag ansåg som det svåraste - att koppla ihop logiska volymer med en flashprocedur som utför alla uppskjutna åtgärder i reiser4. Allt detta är fortfarande i den experimentella "format41"-grenen.

Klarar Reiser4 xfstests?

Åtminstone gjorde det det för mig när jag förberedde den senaste releasen.

Är det i princip möjligt att göra Reiser4 till ett nätverk (kluster) FS med hjälp av plugins?

Det är möjligt, och till och med nödvändigt! Om du skapar en nätverksfil baserad på ett korrekt designat lokalt filsystem kommer resultatet att bli mycket imponerande! I moderna nätverks-FS:er är jag inte nöjd med närvaron av en backend-lagringsnivå, som implementeras med vilken lokal FS som helst. Förekomsten av denna nivå är helt omotiverad. Nätverket FS måste interagera direkt med blocklagret och inte be den lokala FS att skapa några andra servicefiler!

I allmänhet är uppdelning av filsystem i lokala och nätverk från det onda. Det härrörde från ofullkomligheten i de algoritmer som användes för trettio år sedan, och i stället för vilka ingenting ännu har föreslagits. Detta är också anledningen till uppkomsten av en massa onödiga programvarukomponenter (olika tjänster, etc.). På ett bra sätt borde det bara finnas en FS i form av en kärnmodul och en uppsättning användarverktyg installerade på varje maskin - en klusternod. Denna FS är både lokal och nätverk. Och inget mer!

Om inget funkar med Reiser4 på Linux så skulle jag vilja erbjuda en FS för FreeBSD (citat från en tidigare intervju: “...FreeBSD... har akademiska rötter... Och detta betyder att vi med stor sannolikhet kommer att hitta ett gemensamt språk med utvecklarna”) ?

Så, som vi nyss fick reda på, har allt redan fungerat perfekt med Linux: det finns en separat fungerande Reiser4-port för det i form av en huvudgren av vårt arkiv. Jag har inte glömt FreeBSD! Erbjudande! Jag är redo att arbeta nära dem som känner till FreeBSDs inre. Förresten: det jag verkligen gillar med deras community är att besluten där fattas av ett uppdaterat råd av oberoende experter, vilket inte har något att göra med regeringens bedrägeri av en permanent person.

Hur betygsätter du Linux-användargemenskapen idag? Har det blivit mer "pop"?

Med tanke på arten av mitt arbete är det ganska svårt för mig att bedöma detta. Oftast kommer användare till mig med felrapporter och förfrågningar om att fixa avsnittet. Användare som användare. Vissa är mer kunniga, andra mindre. Alla behandlas likadant. Tja, om användaren ignorerar mina instruktioner, ursäkta mig: Ignoreringsordern kommer att läggas in från min sida också.

Är det möjligt att förutse utvecklingen av filsystem för de kommande fem till tio åren? Vilka tror du är de största utmaningarna som FS-utvecklare kan ställas inför?

Ja, det är inte svårt att göra en sådan prognos. Det har inte skett någon utveckling av filsystem i upstream på länge. Endast utseendet på sådana skapas. Utvecklare av lokala filsystem stötte på problem i samband med dålig design. En varning måste göras här. Jag anser inte att den så kallade "lagringen", "slickningen" och porteringen av kod är utveckling och utveckling. Och jag klassificerar inte missförståndet som kallas "Btrfs" som en utveckling av de skäl som jag redan har förklarat.

Varje plåster gör bara sina problem värre. Väl. och det finns alltid olika typer av "evangelister" för vilka "allt fungerar". I grund och botten är det skolbarn och studenter som hoppar över föreläsningar. Föreställ dig bara: det fungerar för honom, men professorn gör det inte. Vilken adrenalinkick det här är! Ur min synvinkel orsakas den största skadan av "hantverkarna" som skyndade sig att entusiastiskt "skruva" de underbara egenskaperna hos Btrfs på alla möjliga lager som systemd, docker, etc. - detta liknar redan metastaser.

Låt oss nu försöka göra en prognos för fem till tio år. Jag har redan kort listat vad vi kommer att göra i Reiser4. Den största utmaningen för lokala FS-utvecklare uppströms kommer att vara (ja, det har det redan blivit) oförmågan att göra ett anständigt jobb för en lön. Utan några idéer inom datalagringsområdet kommer de att fortsätta att försöka patcha dessa olyckliga VFS, XFS och ext4. Situationen med VFS ser särskilt komisk ut mot denna bakgrund, som påminner om den frenetiska moderniseringen av en restaurang där det inte finns några kockar och inga kockar förväntas.

Nu låser VFS-koden, utan några villkor, flera minnessidor samtidigt och uppmanar den underliggande FS att operera på dem. Detta introducerades för att förbättra Ext4s prestanda vid raderingsoperationer, men som är lätt att förstå är sådan samtidig låsning helt oförenlig med avancerade transaktionsmodeller. Det vill säga, du kommer inte bara att kunna lägga till stöd för något smart filsystem i kärnan. Jag vet inte hur situationen är inom andra områden av Linux, men när det gäller filsystem är det osannolikt att någon utveckling här är förenlig med den policy som Torvalds för i praktiken (akademiska projekt sparkas ut, och bedragare som har ingen aning om vad ett B-träd, oändliga krediter av förtroende utfärdas). Därför sattes en kurs mot långsamt förfall. Naturligtvis kommer de att försöka med all sin kraft att framställa det som "utveckling".

Vidare kommer "vårdarna" av filsystem, som inser att du inte kan tjäna mycket på enbart "lagring", försöka sig på en mer lönsam verksamhet. Dessa är som regel distribuerade filsystem och virtualisering. Kanske kommer de att porta den fashionabla ZFS någon annanstans där den inte finns ännu. Men det, som alla FS från uppströms, liknar ett nyårsträd: om du kan hänga några andra små saker på toppen, kan du inte bli djupare. Jag erkänner att det är möjligt att bygga ett seriöst företagssystem baserat på ZFS, men eftersom vi nu diskuterar framtiden kan jag tyvärr bara konstatera att ZFS är hopplöst i detta avseende: med sina virtuella enheter har killarna stängt av syret för sig själva och kommande generationer för vidare utveckling. ZFS är ett minne blott. Och ext4 och XFS är inte ens i förrgår.

Det är värt att nämna separat om det sensationella konceptet "Linux filsystem för nästa generation". Detta är ett helt politiskt och marknadsföringsprojekt skapat för möjligheten, så att säga, att "fästa framtiden för filsystem" i Linux bakom specifika karaktärer. Faktum är att Linux brukade vara "bara för skojs skull". Men nu är det i första hand en maskin för att tjäna pengar. De är gjorda på allt möjligt. Till exempel är det väldigt svårt att skapa en bra mjukvaruprodukt, men smarta "utvecklare" har länge insett att det inte finns något behov av att anstränga sig alls: du kan framgångsrikt sälja icke-existerande mjukvara som tillkännagavs och marknadsfördes hos alla möjliga offentliga händelser - huvudsaken är att presentationsbilderna ska innehålla fler "funktioner".

Filsystem är perfekta för detta, eftersom du säkert kan pruta i tio år på resultatet. Tja, om någon senare klagar över bristen på just detta resultat, så förstår han helt enkelt ingenting om filsystem! Detta påminner om en finansiell pyramid: i toppen finns äventyrarna som startade denna röra, och de få som hade "tur": de "tog ut utdelningar", d.v.s. fått pengar till utveckling, fått ett välbetalt jobb som chefer, ”visat upp” på konferenser osv.

Därefter kommer de som har "otur": de kommer att räkna förluster, ta itu med konsekvenserna av att distribuera en oanvändbar mjukvaruprodukt i produktion, "osv. Det finns många fler av dem. Tja, vid basen av pyramiden finns en enorm massa utvecklare som "sågar" värdelös kod. De är de största förlorarna, eftersom bortkastad tid inte kan återlämnas. Sådana pyramider är extremt fördelaktiga för Torvalds och hans medarbetare. Och ju fler av dessa pyramider, desto bättre för dem. För att mata sådana pyramider kan vad som helst tas in i kärnan. Offentligt säger man förstås motsatsen. Men jag dömer inte efter ord utan efter handlingar.

Så, "framtiden för filsystem i Linux" är ännu en mycket främjad, men knappast användbar programvara. Efter Btrfs, med hög sannolikhet, kommer platsen för en sådan "framtid" att tas av Bcachefs, vilket är ytterligare ett försök att korsa Linux-blocklagret med ett filsystem (ett dåligt exempel är smittsamt). Och vad är typiskt: det finns samma problem som i Btrfs. Jag misstänkte detta länge, och sedan kunde jag på något sätt inte motstå och tittade in i koden - det är sant!

Författarna till Bcachefs och Btrfs, när de skapade sin FS, använde aktivt andras källor och förstod lite om dem. Situationen påminner mycket om barnens spel "trasig telefon." Och jag kan ungefär föreställa mig hur den här koden kommer att inkluderas i kärnan. Egentligen kommer ingen att se "rakarna" (alla kommer att trampa på dem senare). Efter många käbblar om stilen på koden, anklagelser om icke-existerande kränkningar, etc., kommer en slutsats att göras om författarens "lojalitet", hur väl han "interagerar" med andra utvecklare och hur framgångsrikt allt detta kan göras. sedan säljas till företag.

Slutresultatet kommer inte att intressera någon. För tjugo år sedan kanske jag hade varit intresserad, men nu ställs frågorna annorlunda: går det att främja detta så att vissa personer kommer att anställas inom de närmaste tio åren. Och tyvärr är det inte brukligt att undra över slutresultatet.

Generellt skulle jag starkt avråda från att börja återuppfinna ditt filsystem från början. För inte ens betydande finansiella investeringar kommer att räcka för att få något konkurrenskraftigt om tio år. Naturligtvis pratar jag om seriösa projekt, och inte om de som är avsedda att "skjutas" in i kärnan. Så ett mer effektivt sätt att uttrycka dig är att gå med i verkliga utvecklingar, som vi. Detta är naturligtvis inte lätt att göra – men så är fallet med alla projekt på hög nivå.

Först måste du självständigt övervinna problemet som jag kommer att erbjuda. Därefter, övertygad om allvaret i dina avsikter, kommer jag att börja hjälpa till. Traditionellt använder vi bara våra egna utvecklingar. Undantagen är komprimeringsalgoritmer och vissa hashfunktioner. Vi skickar inte utvecklare för att resa till konferenser, och då sitter vi inte och kombinerar andras idéer ("kanske vad som kommer att hända"), som är brukligt i de flesta startups.

Vi utvecklar alla algoritmer själva. Jag är för närvarande intresserad av de algebraiska och kombinatoriska aspekterna av datalagringsvetenskap. I synnerhet ändliga fält, asymptotik, bevis på ojämlikheter. Det finns också arbete för vanliga programmerare, men jag måste varna dig omedelbart: alla förslag om att "titta på en annan FS och göra detsamma" ignoreras. Patchar som syftar till närmare integration med Linux via VFS kommer också dit.

Så vi har ingen rake, men vi har en förståelse för vart vi behöver röra oss, och vi är övertygade om att den här riktningen är den rätta. Denna förståelse kom inte i form av manna från himlen. Låt mig påminna dig om att vi har 29 års erfarenhet av utveckling bakom oss, två filsystem skrivna från grunden. Och samma antal dataåterställningsverktyg. Och det här är mycket!

Källa: opennet.ru