Het tweede interview met Eduard Shishkin, ontwikkelaar van het Reiser4-bestandssysteem, is gepubliceerd.
Herinner de lezers er om te beginnen aan waar en voor wie u werkt.
Ik werk als Principal Storage Architect bij Huawei Technologies, German Research Center. Op de afdeling virtualisatie houd ik me bezig met verschillende aspecten van dataopslag. Mijn werkzaamheden zijn niet gerelateerd aan een specifiek besturingssysteem.
Maak je momenteel een commit aan de hoofdkernelbranch?
Zeer zelden, en alleen als mijn werkgever dit vereist. De laatste keer was ongeveer drie jaar geleden dat ik patches stuurde om de doorvoer te vergroten voor opslag die op hosts werd gedeeld met behulp van het 9p-protocol (een andere naam voor dit bedrijf is VirtFS). Hier moet een belangrijke opmerking worden gemaakt: hoewel ik al heel lang met Linux werk, ben ik er nooit een fan van geweest, dat wil zeggen: ik "adem gelijkmatig", zoals met al het andere. Vooral als ik een gebrek constateer, kan ik er hoogstens één keer op wijzen. En zodat je dan iemand kunt volgen en overtuigen - dit zal niet gebeuren.
Ik herinner me dat je de vorige keer, tien jaar geleden, nogal kritisch was over de kernelontwikkelingsstijl. Is er vanuit uw (of misschien bedrijfs)perspectief iets veranderd, is de gemeenschap responsiever geworden of niet? Zo niet, wie is dan volgens u de schuldige?
Ik heb nooit enige verandering ten goede gezien. Het grootste probleem van de gemeenschap is de vervanging van wetenschap door politieke technologieën, persoonlijke relaties, meerderheidsopinie, populisme, advies van ‘innerlijke stemmen’, rotte compromissen, alles behalve wetenschap. Informatica is, wat je ook zegt, in de eerste plaats een exacte wetenschap. En als iemand zijn eigen waarde voor 2x2, anders dan 4, begint te verkondigen onder de vlag van "Linux Way", of onder een andere vlag, dan is het onwaarschijnlijk dat dit iets anders dan schade zal aanrichten.
Alle problemen zijn in de eerste plaats te wijten aan de incompetentie en het gebrek aan opleiding van degenen die beslissingen nemen. Als een manager incompetent is, is hij niet in staat een objectieve, adequate beslissing te nemen. Als hij bovendien onbeschaafd is, kan hij geen competente specialist vinden die hem het juiste advies zal geven. Met grote waarschijnlijkheid zal de keuze vallen op een oplichter die ‘schijnbaar correcte dingen’ zegt. Er ontstaat altijd een corrupte omgeving rond incompetente eenzame leiders. Bovendien kent de geschiedenis op dit vlak geen uitzonderingen, en de gemeenschap is hiervan de duidelijkste bevestiging.
Hoe beoordeelt u de voortgang in de ontwikkeling van Btrfs? Heeft deze FS kinderziekten weggenomen? Hoe positioneer je het voor jezelf - als FS “voor thuis” of ook voor zakelijk gebruik?
Ik ben er niet vanaf gekomen. Alles wat ik 11 jaar geleden noemde, is vandaag de dag nog steeds relevant. Een van de problemen met Btrfs die het ongeschikt maakt voor serieuze behoeften is het probleem van de vrije ruimte. Ik heb het niet eens over het feit dat de gebruiker wordt gevraagd naar de winkel te rennen voor een nieuwe schijf in situaties waarin een andere FS veel vrije ruimte op de partitie zou tonen. Het onvermogen om een bewerking op een logisch volume te voltooien vanwege een gebrek aan vrije ruimte is ook niet het ergste. Het ergste is dat een gebruiker zonder rechten bijna altijd schijfquota kan omzeilen en iedereen in vrij korte tijd van vrije ruimte kan beroven.
Het ziet er zo uit (getest voor Linux kernel 5.12). Er wordt een script gestart op een nieuw geïnstalleerd systeem, dat in een lus bestanden met bepaalde namen in de thuismap maakt, er met bepaalde verschuivingen gegevens naartoe schrijft en deze bestanden vervolgens verwijdert. Nadat dit script een minuut is uitgevoerd, gebeurt er niets ongewoons. Na vijf minuten neemt het gedeelte van de bezette ruimte op de scheidingswand iets toe. Na twee tot drie uur bereikt het 50% (met een initiële waarde van 15%). En na vijf of zes uur werken crasht het script met de foutmelding “er is geen vrije ruimte op de partitie.” Hierna kunt u zelfs geen 4K-bestand meer naar uw partitie schrijven.
Er doet zich een interessante situatie voor: je hebt uiteindelijk niets naar de partitie geschreven en alle vrije ruimte (ongeveer 85%) is ergens verdwenen. Analyse van een sectie die aan een dergelijke aanval wordt blootgesteld, zal veel boomknooppunten onthullen die slechts één item (een object uitgerust met een sleutel) bevatten, dat meerdere bytes groot is. Dat wil zeggen, de inhoud die voorheen 15% van de schijfruimte in beslag nam, bleek gelijkmatig over de hele partitie te zijn "uitgesmeerd", zodat er nergens een nieuw bestand kan worden geschreven, omdat de sleutel groter is dan alle bestaande, en de gratis blokken op de partitie zijn op.
Bovendien gebeurt dit allemaal al in de basisconfiguratie van Btrfs (zonder snapshots, subvolumes, enz.), en het maakt niet uit hoe u besluit de bestandslichamen in dat FS op te slaan (als “fragmenten” in een boom, of als uitbreidingen van niet-geformatteerde blokken) - het eindresultaat zal hetzelfde zijn.
U kunt andere upstream-bestandssystemen niet aan een dergelijke aanval onderwerpen (wat ze u ook vertellen). Ik heb de oorzaak van het probleem al lang geleden uitgelegd: dit is een volledige perversie van het B-tree-concept in Btrfs, waardoor het spontaan of opzettelijk kan degenereren. In het bijzonder zal uw bestandssysteem onder bepaalde belasting voortdurend “uit elkaar vallen” tijdens het zelfstandig functioneren, zonder hulp van buitenaf. Het is duidelijk dat allerlei "dringende" achtergrondprocessen alleen op individuele desktops de dag zullen redden.
Op collectieve servers kan een aanvaller ze altijd ‘voorlopen’. De systeembeheerder zal niet eens kunnen vaststellen wie hem precies heeft gepest. De snelste manier om dit probleem in Btrfs op te lossen is door de structuur van een gewone B-boom te herstellen, d.w.z. het opnieuw ontwerpen van het schijfformaat en het herschrijven van aanzienlijke delen van de Btrfs-code. Dit zal 8-10 jaar duren, inclusief debuggen, op voorwaarde dat de ontwikkelaars de originele artikelen over de relevante algoritmen en datastructuren strikt volgden en niet het “kapote telefoon”-spel speelden, zoals gebruikelijk (en aangemoedigd) in de “Linux”-versie. manier".
Hier moeten we ook de tijd toevoegen die ontwikkelaars nodig hebben om dit allemaal te begrijpen. Dit is waar het moeilijker wordt. Hoe dan ook, tien jaar was voor hen niet genoeg om het te begrijpen. Nou ja, tot die tijd kun je niet op een wonder hopen. Het zal niet gebeuren in de vorm van een montageoptie “waar jij en ik niets van wisten”, of in de vorm van een patch die “gewoon een kwestie van zaken” is om voor te bereiden. Voor elke dergelijke overhaaste ‘oplossing’ zal ik een nieuw scenario van degeneratie presenteren. B-bomen zijn een van mijn favoriete onderwerpen, en ik moet zeggen dat deze structuren geen vrijheden tegenover zichzelf tolereren!
Hoe positioneer ik Btrfs voor mezelf? Als iets dat absoluut geen bestandssysteem kan worden genoemd, laat staan gebruikt. Omdat de FS per definitie een OS-subsysteem is dat verantwoordelijk is voor het effectieve beheer van de “schijfruimte” -bron, wat we niet zien in het geval van Btrfs. Stel je voor dat je naar de winkel kwam om een horloge te kopen om niet te laat op je werk te komen, en in plaats van een horloge verkochten ze je een elektrische grill met een timer voor maximaal 30 minuten. De situatie met Btrfs is dus nog erger.
Als ik door mailinglijsten blader, kom ik vaak de stelling tegen dat het effectief beheren van schijfruimte niet langer relevant is vanwege de lage prijs van schijven. Dit is complete onzin. Zonder een effectieve schijfruimtebeheerder wordt het besturingssysteem kwetsbaar en onbruikbaar. Ongeacht de capaciteit van de schijven op uw machine.
Ik zou graag om commentaar willen vragen over de stopzetting van de Btrfs-ondersteuning in RHEL.
Er valt hier niets bijzonders op te merken, alles is heel duidelijk. Ze hadden het ook als een “technologiepreview”. Dus ik heb deze “preview” niet doorlopen. Laat dit label niet eeuwig hangen! Maar ze kunnen geen gebrekkig bijontwerpproduct lanceren met volledige ondersteuning. RHEL is een onderneming, dat wil zeggen voorgeschreven verhoudingen tussen goederen en geld. Red Hat kan gebruikers niet pesten zoals op de Btrfs-mailinglijst. Stel je de situatie eens voor: een klant die zijn zuurverdiende geld voor de schijf heeft betaald en ook jij voor ondersteuning, wil weten waar zijn schijfruimte naartoe is gegaan nadat hij niets heeft opgeschreven. Wat ga je hem hierop antwoorden?
Verder. Tot de klanten van Red Hat behoren bekende grote banken en beurzen. Stel je voor wat er zou gebeuren als ze onderworpen zouden worden aan DoS-aanvallen op basis van de genoemde kwetsbaarheid in Btrfs. Wie is hier volgens jou verantwoordelijk voor? Tegen degenen die op het punt staan met de vinger te wijzen naar de regel van de GPL-licentie, waar geschreven staat dat de auteur nergens verantwoordelijk voor is, zal ik meteen zeggen: “verberg het maar!” Red Hat zal antwoorden, en wel op zo’n manier dat het niet genoeg lijkt! Maar ik weet dat Red Hat niet met dit soort problemen wordt geconfronteerd, gezien hun bijzonder sterke team van QA-ingenieurs met wie ik in mijn tijd nauw heb mogen samenwerken.
Waarom blijven sommige bedrijven Btrfs ondersteunen in hun zakelijke producten?
Houd er rekening mee dat het voorvoegsel ‘onderneming’ in de productnaam niet veel betekent. Ondernemen is een maatstaf voor verantwoordelijkheid die is ingebed in de contractuele relatie met de klant. Ik ken slechts één onderneming gebaseerd op GNU/Linux: RHEL. Al het andere wordt, vanuit mijn standpunt, alleen gepresenteerd als een onderneming, maar is dat niet. En ten slotte: als er ergens vraag naar is, zal er altijd aanbod zijn (in ons geval is dit de genoemde ‘ondersteuning’). Er is vraag naar werkelijk alles, incl. en onbruikbare software. Hoe een dergelijke vraag wordt gevormd en wie deze voedt, is een ander onderwerp.
Ik zou dus geen conclusies trekken nadat het gerucht gaat dat Facebook Btrfs op zijn servers heeft geïmplementeerd. Bovendien zou ik om bovengenoemde redenen aanraden de adressen van die servers zorgvuldig geheim te houden.
Waarom is er de laatste tijd zoveel moeite gestoken in het opschonen van de XFS-code? In eerste instantie is dit immers een bestandssysteem van derden, en ext4 is al lange tijd stabiel en heeft continuïteit met eerdere, even stabiele versies. Welk belang heeft Red Hat in XFS? Heeft het zin om actief twee bestandssystemen te ontwikkelen die qua doel vergelijkbaar zijn: ext4 en XFS?
Ik kan me niet herinneren wat dit motiveerde. Het is heel goed mogelijk dat het initiatief afkomstig was van klanten van Red Hat. Ik herinner me dat dit soort onderzoek werd uitgevoerd: op sommige bestandssystemen van upstream werden een gigantisch aantal objecten gemaakt op geavanceerde schijven van de nieuwe generatie. Volgens de resultaten gedroeg XFS zich beter dan ext4. Dus begonnen ze het te promoten als het meest veelbelovende. Ik zou hier in ieder geval niets sensationeels zoeken.
Voor mij is het alsof ze een priem hebben vervangen door zeep. Het heeft geen zin om ext4 en XFS te ontwikkelen. Zowel parallel als elk van hen om uit te kiezen. Hier zal niets goeds uit voortkomen. Hoewel er in de natuur vaak situaties zijn waarin er veel groeipotentieel is, maar er geen ruimte is om te groeien. In dit geval ontstaan er verschillende bizar lelijke nieuwe gezwellen, waar iedereen met de vinger naar wijst (“Oh, kijk, wat zul je in dit leven niet zien!”).
Denkt u dat de kwestie van laagschending (in negatieve zin) is opgelost met de komst van encryptiefuncties in ext4, F2FS (om nog maar te zwijgen van RAID in Btrfs)?
Over het algemeen is de introductie van welk niveau dan ook en het nemen van een beslissing over het niet-overtreden ervan meestal een kwestie van beleid, en ik verbind mij er niet toe om hier ergens commentaar op te geven. De objectieve aspecten van laagschending zijn voor niemand van belang, maar we kunnen er enkele bekijken aan de hand van het voorbeeld van schending ‘van bovenaf’, namelijk de implementatie in de FS van functionaliteit die al bestaat op de bloklaag. Een dergelijke ‘schending’ is gerechtvaardigd, met slechts zeldzame uitzonderingen. Voor elk dergelijk geval moet je eerst twee dingen bewijzen: dat het echt nodig is, en dat het ontwerp van het systeem hierdoor niet wordt geschaad.
Spiegelen, wat van oudsher een activiteit voor de bloklaag is, is bijvoorbeeld zinvol om op bestandssysteemniveau te implementeren. Voor verschillende redenen. Er vindt bijvoorbeeld ‘stille’ datacorruptie (bitrot) plaats op schijfstations. Dit is wanneer het apparaat goed werkt, maar de blokgegevens onverwacht worden beschadigd onder invloed van een hard gammakwantum dat wordt uitgezonden door een verre quasar, enz. Het ergste is als dit blok een FS-systeemblok blijkt te zijn (superblok, bitmapblok, opslagboomknooppunt, enz.), omdat dit zeker tot kernelpaniek zal leiden.
Houd er rekening mee dat de spiegels die door de bloklaag worden aangeboden (de zogenaamde RAID 1) u niet van dit probleem zullen redden. Nou ja, echt: iemand zou de checksums moeten controleren en de replica moeten lezen in geval van een storing? Bovendien is het zinvol om niet alleen alles te spiegelen, maar alleen de metadata. Sommige belangrijke gegevens (bijvoorbeeld uitvoerbare bestanden van kritieke applicaties) kunnen als metadata worden opgeslagen. In dit geval krijgen ze dezelfde veiligheidsgaranties. Het is zinvol om de bescherming van de resterende gegevens aan andere subsystemen (misschien zelfs gebruikersapplicaties) toe te vertrouwen - we hebben hiervoor alle noodzakelijke voorwaarden geboden.
Dergelijke ‘economische’ spiegelservers hebben bestaansrecht en kunnen alleen effectief worden georganiseerd op het niveau van het bestandssysteem. Anders zorgt het schenden van de gelaagdheid ervoor dat een subsysteem wordt volgestopt met dubbele code omwille van enkele microscopische voordelen. Een treffend voorbeeld hiervan is de implementatie van RAID-5 met behulp van FS. Dergelijke oplossingen (eigen RAID / LVM in het bestandssysteem) doden deze laatste in architectonische termen. Er moet hier ook worden opgemerkt dat schending van de gelaagdheid door verschillende soorten marketingoplichters ‘in de lucht wordt gezet’. Bij gebrek aan ideeën wordt functionaliteit die al lang op aangrenzende niveaus is geïmplementeerd aan de subsystemen toegevoegd, dit wordt gepresenteerd als een nieuwe, uiterst nuttige functie en wordt actief gepusht.
Reiser4 werd beschuldigd van het overtreden van de niveaus “van onderaf”. Gebaseerd op het feit dat het bestandssysteem niet monolithisch is, zoals alle andere, maar modulair, werd een ongefundeerde aanname gedaan dat het doet wat het niveau erboven (VFS) zou moeten doen.
Is het mogelijk om te praten over de dood van ReiserFS v3.6 en bijvoorbeeld JFS? De laatste tijd hebben ze in de kern vrijwel geen aandacht gekregen. Zijn ze verouderd?
Hier moeten we definiëren wat de dood van een softwareproduct betekent. Aan de ene kant worden ze met succes gebruikt (daar zijn ze tenslotte voor gemaakt), wat betekent dat ze leven. Aan de andere kant kan ik niet voor JFS spreken (ik weet niet veel), maar ReiserFS (v3) is erg moeilijk aan te passen aan nieuwe trends (in de praktijk getest). Dit betekent dat ontwikkelaars er in de toekomst niet op zullen letten, maar op degenen die gemakkelijker aan te passen zijn. Van deze kant blijkt dat het helaas architectonisch dood is. Ik zou het concept van ‘moreel achterhaald’ helemaal niet manipuleren. Het is bijvoorbeeld goed van toepassing op een kledingkast, maar niet op softwareproducten. Er is een concept van minderwaardigheid en superioriteit in iets. Ik kan absoluut zeggen dat ReserFS v3 nu in alles inferieur is aan Reiser4, maar in sommige soorten werklast is het superieur aan alle andere upstream FS's.
Kent u de ontwikkeling van FS Tux3 en HAMMER/HAMMER2 (FS voor DragonFly BSD)?
Ja, dat weten we. In Tux3 was ik ooit geïnteresseerd in de technologie van hun snapshots (de zogenaamde “versiewijzers”), maar in Reiser4 zullen we hoogstwaarschijnlijk een andere route bewandelen. Ik heb er lang over nagedacht om snapshots te ondersteunen, maar ik heb nog niet besloten hoe ik deze voor eenvoudige Reiser4-volumes moet implementeren. Feit is dat de nieuwerwetse ‘luie’ referentietellertechniek, voorgesteld door Ohad Rodeh, alleen werkt voor B-trees. Wij hebben ze niet. Voor de datastructuren die in Reiesr4 worden gebruikt, zijn "luie" tellers niet gedefinieerd - om ze te introduceren is het noodzakelijk om bepaalde algoritmische problemen op te lossen, die nog niemand heeft aangepakt.
Volgens HAMMER: Ik heb een artikel van de maker gelezen. Niet geïnteresseerd. Nogmaals, B-bomen. Deze datastructuur is hopeloos verouderd. We hebben het in de vorige eeuw verlaten.
Hoe beoordeelt u de groeiende vraag naar netwerkcluster-FS's zoals CephFS/GlusterFS/etc? Betekent deze vraag een verschuiving in de prioriteiten van ontwikkelaars richting netwerk-FS en onvoldoende aandacht voor lokale FS?
Ja, een dergelijke verschuiving in prioriteiten heeft plaatsgevonden. De ontwikkeling van lokale bestandssystemen is gestagneerd. Helaas is iets belangrijks doen voor lokale volumes nu behoorlijk moeilijk en niet iedereen kan het. Niemand wil investeren in hun ontwikkeling. Dit is ongeveer hetzelfde als het vragen aan een commerciële organisatie om geld uit te trekken voor wiskundig onderzoek - zonder enig enthousiasme zullen ze je vragen hoe je geld kunt verdienen met een nieuwe stelling. Nu is een lokale FS iets dat op magische wijze “out of the box” verschijnt en “altijd zou moeten werken”, en als het niet werkt, veroorzaakt het ongeadresseerd gemopper als: “Ja, wat denken ze wel!”
Vandaar het gebrek aan aandacht voor lokale FS, hoewel er op dat gebied nog veel werk is. En ja, iedereen heeft zich tot gedistribueerde opslag gewend, die is gebouwd op basis van reeds bestaande lokale bestandssystemen. Het is nu erg in de mode. De uitdrukking ‘Big Data’ veroorzaakt bij velen een adrenalinekick en associeert het met conferenties, workshops, hoge salarissen, enz.
Hoe redelijk is het in principe om het netwerkbestandssysteem in de kernelruimte te implementeren in plaats van in de gebruikersruimte?
Een zeer redelijke aanpak die nog nergens is geïmplementeerd. Over het algemeen is de vraag in welke ruimte een netwerkbestandssysteem moet worden geïmplementeerd een ‘tweesnijdend zwaard’. Laten we eens naar een voorbeeld kijken. De klant heeft gegevens vastgelegd op een externe machine. Ze vielen in haar paginacache in de vorm van vuile pagina's. Dit is de taak voor een "thin gateway" netwerkbestandssysteem in de kernelruimte. Dan zal het besturingssysteem u vroeg of laat vragen om die pagina's naar schijf te schrijven om ze vrij te maken. Dan komt de IO-doorsturende (verzendende) netwerk-FS-module in beeld. Het bepaalt naar welke servermachine (serverknooppunt) deze pagina's gaan.
Vervolgens neemt de netwerkstack het over (en, zoals we weten, wordt deze geïmplementeerd in de kernelruimte). Vervolgens ontvangt het serverknooppunt dat pakket met gegevens of metagegevens en instrueert het de backend-opslagmodule (dat wil zeggen de lokale FS die in de kernelruimte werkt) om al deze dingen op te nemen. Daarom hebben we de vraag teruggebracht tot waar de modules “verzenden” en “ontvangen” zouden moeten werken. Als een van deze modules in de gebruikersruimte draait, zal dit onvermijdelijk leiden tot contextwisseling (vanwege de noodzaak om kernelservices te gebruiken). Het aantal van dergelijke schakelaars is afhankelijk van de implementatiedetails.
Als er veel van dergelijke switches zijn, zal de opslagdoorvoer (I/O-prestaties) afnemen. Als uw backend-opslag uit langzame schijven bestaat, merkt u geen significante daling. Maar als je snelle schijven hebt (SSD, NVRAM, etc.), dan wordt contextwisseling al een “knelpunt” en door te besparen op contextwisseling kunnen de prestaties aanzienlijk worden verhoogd. De standaardmanier om geld te besparen is door modules naar de kernelruimte te verplaatsen. We ontdekten bijvoorbeeld dat het verplaatsen van de 9p-server van QEMU naar de kernel op de hostmachine leidt tot een drievoudige toename van de VirtFS-prestaties.
Dit is natuurlijk geen netwerk-FS, maar het weerspiegelt volledig de essentie van de dingen. Het nadeel van deze optimalisatie zijn draagbaarheidsproblemen. Voor sommigen kan dit laatste van cruciaal belang zijn. GlusterFS heeft bijvoorbeeld helemaal geen modules in de kernel. Dankzij dit werkt het nu op veel platforms, waaronder NetBSD.
Welke concepten kunnen lokale FS's lenen van netwerk-FS's en vice versa?
Tegenwoordig hebben netwerk-FS's in de regel add-ons op lokale FS's, dus ik begrijp niet helemaal hoe je iets van laatstgenoemde kunt lenen. Laten we inderdaad eens kijken naar een bedrijf met 4 werknemers, waarin iedereen zijn eigen ding doet: de een distribueert, de ander verzendt, de derde ontvangt, de vierde slaat op. En de vraag wat het bedrijf kan lenen van de medewerker die het opslaat, klinkt op de een of andere manier onjuist (het heeft al heel lang wat het van hem had kunnen lenen).
Maar lokale FS'en kunnen veel leren van netwerk-FS'en. Ten eerste moet u van hen leren hoe u logische volumes op een hoog niveau kunt aggregeren. Nu de zgn “geavanceerde” lokale bestandssystemen aggregeren logische volumes uitsluitend met behulp van “virtuele apparaat”-technologie die is geleend van LVM (dezelfde infectieuze gelaagdheidsschending die voor het eerst werd geïmplementeerd in ZFS). Met andere woorden, de vertaling van virtuele adressen (bloknummers) naar echte adressen en terug vindt plaats op een laag niveau (d.w.z. nadat het bestandssysteem een I/O-verzoek heeft uitgegeven).
Houd er rekening mee dat het toevoegen en verwijderen van apparaten aan logische volumes (geen spiegels) die op de bloklaag zijn gerangschikt, tot problemen leidt waar leveranciers van dergelijke “functies” bescheiden over zwijgen. Ik heb het over fragmentatie op echte apparaten, die monsterlijke waarden kunnen bereiken, terwijl op een virtueel apparaat alles in orde is. Er zijn echter maar weinig mensen geïnteresseerd in virtuele apparaten: iedereen is geïnteresseerd in wat er op je echte apparaten gebeurt. Maar ZFS-achtige FS (evenals elke FS in combinatie met LVM) werkt alleen met virtuele schijfapparaten (wijs virtuele schijfadressen toe uit vrije adressen, defragmenteer deze virtuele apparaten, enz.). En ze hebben geen idee wat er op echte apparaten gebeurt!
Stel je nu voor dat je geen enkele fragmentatie hebt op het virtuele apparaat (dat wil zeggen, je hebt daar maar één gigantische omvang), je voegt een schijf toe aan je logische volume, en verwijdert dan nog een willekeurige schijf uit je logische volume en brengt vervolgens opnieuw in evenwicht. En zo vaak. Het is niet moeilijk voor te stellen dat je op het virtuele apparaat nog steeds in dezelfde mate leeft, maar op echte apparaten zul je niets goeds zien.
Het ergste is dat je deze situatie niet eens kunt corrigeren! Het enige dat u hier kunt doen, is het bestandssysteem vragen het virtuele apparaat te defragmenteren. Maar ze zal je vertellen dat alles daar geweldig is - er is maar één omvang, de fragmentatie is nul en het kan niet beter zijn! Logische volumes die op blokniveau zijn gerangschikt, zijn dus niet bedoeld voor het herhaaldelijk toevoegen/verwijderen van apparaten. Op een goede manier hoeft u slechts één keer een logisch volume op blokniveau samen te stellen, het aan het bestandssysteem te geven en er vervolgens niets anders mee te doen.
Bovendien maakt de combinatie van onafhankelijke FS+LVM-subsystemen het niet mogelijk om rekening te houden met de verschillende aard van de schijven waaruit logische volumes worden samengevoegd. Stel dat u een logisch volume hebt samengesteld uit HDD- en SSD-apparaten. Maar dan zal voor de eerste defragmentatie nodig zijn, en voor de laatste niet. Voor het laatste moet u teruggooiverzoeken indienen, maar voor het eerste niet, enz. In deze combinatie is het echter vrij moeilijk om een dergelijke selectiviteit aan te tonen.
Houd er rekening mee dat de situatie niet veel beter wordt nadat u uw eigen LVM op het bestandssysteem hebt gemaakt. Bovendien maak je daarmee feitelijk een einde aan het vooruitzicht om dit in de toekomst ooit te verbeteren. Dit is erg slecht. Op dezelfde machine kunnen verschillende soorten schijven voorkomen. En als het bestandssysteem daar geen onderscheid tussen maakt, wie dan wel?
Een ander probleem ligt op de loer voor de zogenaamde. “Write-Anywhere”-bestandssystemen (dit omvat ook Reiser4, als u tijdens het aankoppelen het juiste transactiemodel hebt opgegeven). Dergelijke bestandssystemen moeten defragmentatietools bieden die ongekend krachtig zijn. En de volumemanager op laag niveau helpt hier niet, maar staat alleen maar in de weg. Het is een feit dat uw FS met zo'n manager een kaart met vrije blokken van slechts één apparaat opslaat - een virtueel apparaat. Dienovereenkomstig kunt u alleen een virtueel apparaat defragmenteren. Dit betekent dat uw defragmentatieprogramma heel lang zal werken op een enorme enkele ruimte met virtuele adressen.
En als veel gebruikers willekeurige overschrijvingen uitvoeren, wordt het nuttige effect van zo'n defragmentatie tot nul gereduceerd. Uw systeem zal onvermijdelijk beginnen te vertragen, en u hoeft alleen maar uw handen te vouwen voor de teleurstellende diagnose ‘kapot ontwerp’. Verschillende defragmentatieprogramma's die op dezelfde adresruimte draaien, zullen elkaar alleen maar hinderen. Het is een heel andere zaak als je voor elk echt apparaat je eigen kaart met vrije blokken bijhoudt. Dit zal het defragmentatieproces effectief parallelliseren.
Maar dit kan alleen worden gedaan als u over een logische volumemanager op hoog niveau beschikt. Lokale bestandssystemen met dergelijke managers bestonden voorheen niet (ik ken ze tenminste niet). Alleen netwerkbestandssystemen (bijvoorbeeld GlusterFS) hadden dergelijke managers. Een ander zeer belangrijk voorbeeld is het hulpprogramma Volume Integrity Check (fsck). Als u voor elk subvolume uw eigen onafhankelijke kaart van vrije blokken opslaat, kan de procedure voor het controleren van een logisch volume effectief worden geparallelliseerd. Met andere woorden: logische volumes met managers op hoog niveau schalen beter.
Bovendien kunt u met volumemanagers op laag niveau geen volwaardige snapshots organiseren. Met LVM- en ZFS-achtige bestandssystemen kunt u alleen lokale snapshots maken, maar geen globale snapshots. Met lokale snapshots kunt u alleen reguliere bestandsbewerkingen onmiddellijk terugdraaien. En niemand daar zal bewerkingen met logische volumes (apparaten toevoegen/verwijderen) terugdraaien. Laten we dit eens bekijken met een voorbeeld. Op een gegeven moment, als je een logisch volume hebt van twee apparaten A en B met 100 bestanden, maak je een momentopname van systeem S en maak je vervolgens nog eens honderd bestanden.
Daarna voegt u apparaat C toe aan uw volume en draait u uiteindelijk uw systeem terug naar snapshot S. Vraag: Hoeveel bestanden en apparaten bevat uw logische volume na het terugdraaien naar S? Er zullen 100 bestanden zijn, zoals je misschien al geraden had, maar er zullen 3 apparaten zijn - dit zijn dezelfde apparaten A, B en C, hoewel er op het moment dat de momentopname werd gemaakt er slechts twee apparaten in het systeem waren (A en B ). De bewerking voor het toevoegen van apparaat C is niet ongedaan gemaakt en als u nu apparaat C van de computer verwijdert, zullen uw gegevens beschadigd raken. Voordat u het apparaat verwijdert, moet u dus eerst een dure bewerking uitvoeren om het apparaat te verwijderen uit het logische volume dat opnieuw in evenwicht is gebracht. zal alle gegevens van apparaat C naar apparaten A en B verspreiden. Maar als uw FS globale snapshots zou ondersteunen, zou een dergelijke herbalancering niet nodig zijn, en na een onmiddellijke terugdraaiing naar S zou u apparaat C veilig van de computer kunnen verwijderen.
Globale snapshots zijn dus goed omdat ze u in staat stellen de kostbare verwijdering (toevoeging) van een apparaat van een logisch volume (naar een logisch volume) met een grote hoeveelheid gegevens te vermijden (uiteraard, als u eraan denkt om uw systeem te “snapshoten”). op het juiste moment). Ik wil u eraan herinneren dat het maken van snapshots en het terugdraaien van het bestandssysteem ernaar onmiddellijke bewerkingen zijn. De vraag kan rijzen: hoe is het überhaupt mogelijk om een operatie op een logisch volume, waar je drie dagen over deed, onmiddellijk terug te draaien? Maar het is mogelijk! Op voorwaarde dat uw bestandssysteem correct is ontworpen. Drie jaar geleden kwam ik op het idee van zulke ‘3D-snapshots’, en vorig jaar heb ik deze techniek gepatenteerd.
Het volgende dat lokale FS's zouden moeten leren van netwerk-FS's is het opslaan van metagegevens op afzonderlijke apparaten op dezelfde manier waarop netwerk-FS's ze op afzonderlijke machines opslaan (de zogenaamde metadata-servers). Er zijn applicaties die voornamelijk met metadata werken, en deze applicaties kunnen enorm versneld worden door de metadata op dure, krachtige opslagapparaten te plaatsen. Met de combinatie FS+LVM kun je een dergelijke selectiviteit niet aantonen: LVM weet niet wat er op het blok staat dat je eraan hebt doorgegeven (data daar of metadata).
Je zult niet veel voordeel halen uit het implementeren van je eigen low-level LVM in de FS vergeleken met de FS+LVM-combinatie, maar wat je heel goed kunt doen is de FS rommelig maken, zodat het later onmogelijk wordt om met de code ervan te werken. ZFS en Btrfs, die overspoeld werden met virtuele apparaten, zijn allemaal duidelijke voorbeelden van hoe schending van gelaagdheid het systeem in architectonische termen doodt. Dus waarom ben ik dit allemaal? Bovendien is het niet nodig om uw eigen LVM op laag niveau in het bestandssysteem te installeren. In plaats daarvan moet u apparaten op een hoog niveau samenvoegen tot logische volumes, zoals sommige netwerkbestandssystemen doen met verschillende machines (opslagknooppunten). Toegegeven, ze doen dit walgelijk vanwege het gebruik van slechte algoritmen.
Voorbeelden van absoluut verschrikkelijke algoritmen zijn de DHT-vertaler in het GlusterFS-bestandssysteem en de zogenaamde CRUSH-map in het Ceph-bestandssysteem. Geen van de algoritmen die ik zag, bevredigde mij in termen van eenvoud en goede schaalbaarheid. Ik moest dus de algebra onthouden en alles zelf uitvinden. In 2015, terwijl ik experimenteerde met bundels in plaats van hashfuncties, bedacht en patenteerde ik iets dat bij mij past. Nu kan ik zeggen dat de poging om dit alles in de praktijk te brengen succesvol was. Ik zie geen problemen met de schaalbaarheid in de nieuwe aanpak.
Ja, voor elk subvolume is een aparte structuur nodig, zoals een superblok in het geheugen. Is dit erg beangstigend? Over het algemeen weet ik niet wie ‘de oceaan gaat koken’ en logische volumes van honderdduizenden of meer apparaten op één lokale machine gaat creëren. Als iemand mij dit kan uitleggen, zal ik u zeer dankbaar zijn. In de tussentijd is dit voor mij marketing-bullshit.
Hoe hebben veranderingen in het kernelblokapparaat-subsysteem (bijvoorbeeld de verschijning van blk-mq) de vereisten voor FS-implementatie beïnvloed?
Ze hadden geen enkele impact. Ik weet niet wat er op de bloklaag zou gebeuren waardoor het nodig zou zijn om een nieuwe FS te ontwerpen. De interactie-interface van deze subsystemen is erg slecht. Aan de kant van de bestuurder zou de FS alleen moeten worden beïnvloed door het verschijnen van nieuwe typen schijven, waaraan eerst de bloklaag zal worden aangepast, en daarna de FS (voor reiser4 betekent dit het verschijnen van nieuwe plug-ins).
Betekent de opkomst van nieuwe soorten media (bijvoorbeeld SMR of de alomtegenwoordigheid van SSD's) fundamenteel nieuwe uitdagingen voor het ontwerp van bestandssystemen?
Ja. En dit zijn normale prikkels voor de ontwikkeling van FS. Uitdagingen kunnen verschillend en volkomen onverwacht zijn. Ik heb bijvoorbeeld gehoord van schijven waarbij de snelheid van een I/O-bewerking sterk afhankelijk is van de grootte van een stukje data en de offset ervan. In Linux, waar de grootte van het FS-blok de paginagrootte niet kan overschrijden, zal een dergelijke schijf standaard niet zijn volledige mogelijkheden tonen. Als uw bestandssysteem echter correct is ontworpen, bestaat de kans dat u er veel meer uit kunt halen.
Hoeveel mensen werken er momenteel naast u met de Reiser4-code?
Minder dan ik zou willen, maar ik ervaar ook geen acuut tekort aan middelen. Ik ben meer dan tevreden met het tempo van de ontwikkeling van Reiser4. Ik ga niet “paarden rijden” - dit is niet het juiste gebied. Hier geldt: “Als je rustiger rijdt, blijf je doorgaan!” Een modern bestandssysteem is het meest complexe kernelsubsysteem, waarvan de verkeerde ontwerpbeslissingen daaropvolgende jaren van menselijk werk ongedaan kunnen maken.
Door vrijwilligers aan te bieden om iets uit te voeren, garandeer ik altijd dat de inspanningen zeker tot het juiste resultaat zullen leiden, waar bij ernstige behoeften vraag naar kan zijn. Zoals u begrijpt, kunnen er niet veel van dergelijke garanties tegelijk zijn. Tegelijkertijd kan ik niet tegen ‘figuren’ die schaamteloos ‘functies’ van duidelijk onbruikbare software promoten, honderden gebruikers en ontwikkelaars misleiden, en tegelijkertijd zitten en glimlachen op kerneltopconferenties.
Heeft een bedrijf zich bereid verklaard de ontwikkeling van Reiser4 te ondersteunen?
Ja, er waren dergelijke voorstellen, incl. en van een grote leverancier. Maar hiervoor moest ik naar een ander land verhuizen. Helaas ben ik geen dertig jaar meer, ik kan niet ontsnappen en bij het eerste fluitsignaal zo vertrekken.
Welke functies ontbreken momenteel in Reiser4?
Er is geen functie voor het wijzigen van de grootte voor eenvoudige volumes, vergelijkbaar met die gevonden in ReiserFS(v3). Bovendien zouden bestandsbewerkingen met de DIRECT_IO-vlag geen kwaad kunnen. Vervolgens zou ik een volume willen kunnen scheiden in “semantische subvolumes”, die geen vaste grootte hebben, en die als onafhankelijke volumes kunnen worden aangekoppeld. Deze problemen zijn goed voor beginners die het ‘echte werk’ willen uitproberen.
En ten slotte zou ik graag logische netwerkvolumes willen hebben met eenvoudige implementatie en beheer (moderne algoritmen maken dit al mogelijk). Maar wat Reiser4 absoluut nooit zal hebben zijn RAID-Z, scrubs, caches voor vrije ruimte, 128-bit variabelen en andere marketingonzin die ontstond tegen de achtergrond van een tekort aan ideeën bij de ontwikkelaars van sommige bestandssystemen.
Kan alles wat nodig is, door plug-ins worden geïmplementeerd?
Als we alleen spreken in termen van interfaces en plug-ins (modules) die ze implementeren, dan niet alles. Maar als je op deze grensvlakken ook relaties introduceert, dan krijg je onder andere de concepten van hogere polymorfismen, waar je al mee uit de voeten kunt. Stel je voor dat je hypothetisch een objectgeoriënteerd runtime-systeem hebt bevroren, de waarde van de instructieaanwijzer hebt gewijzigd zodat deze naar een andere plug-in verwijst die dezelfde X-interface implementeert, en vervolgens het systeem hebt gedeblokkeerd zodat het doorgaat met uitvoeren.
Als de eindgebruiker een dergelijke ‘substitutie’ niet opmerkt, zeggen we dat het systeem een nulde-orde polymorfisme heeft in de X-interface (of dat het systeem heterogeen is in de X-interface, wat hetzelfde is). Als je nu niet alleen een reeks interfaces hebt, maar er ook relaties op hebt (interfacegrafiek), dan kun je polymorfismen van hogere ordes introduceren, die de heterogeniteit van het systeem karakteriseren dat zich al in de "buurt" van elke interface bevindt. Ik heb een dergelijke classificatie lang geleden geïntroduceerd, maar helaas is dit nooit gebeurd.
Met behulp van plug-ins en dergelijke hogere polymorfismen kun je dus elk bekend kenmerk beschrijven, en ook functies 'voorspellen' die nog nooit zijn genoemd. Ik heb dit nog niet strikt kunnen bewijzen, maar een tegenvoorbeeld ken ik ook nog niet. Over het algemeen deed deze vraag me denken aan het “Erlangen-programma” van Felix Klein. Ooit probeerde hij alle meetkunde voor te stellen als een tak van de algebra (in het bijzonder de groepentheorie).
Nu de hoofdvraag: hoe gaat het met de promotie van Reiser4 naar de kern? Waren er publicaties over de architectuur van dit bestandssysteem waarover u in het laatste interview sprak? Hoe relevant is deze vraag vanuit uw standpunt?
Over het algemeen vragen wij al drie jaar om opname in de hoofdtak. Reiser's laatste opmerking in de openbare thread waarin het pull-verzoek werd gedaan, bleef onbeantwoord. Dus alle verdere vragen zijn niet voor ons. Persoonlijk begrijp ik niet waarom we moeten ‘samensmelten’ met een specifiek besturingssysteem. Op Linux convergeerde het licht niet als een wig. Er is dus een aparte repository waarin er verschillende branch-ports voor verschillende besturingssystemen zullen zijn. Wie het nodig heeft, kan de bijbehorende poort klonen en ermee doen wat je wilt (uiteraard binnen de licentie). Nou, als iemand het niet nodig heeft, dan is dat niet mijn probleem. Op dit punt stel ik voor om de kwestie van “promotie naar de belangrijkste Linux-kernel” als afgehandeld te beschouwen.
Publicaties over FS-architectuur zijn relevant, maar tot nu toe heb ik alleen tijd gevonden voor mijn nieuwe resultaten, die ik als een hogere prioriteit beschouw. Een ander ding is dat ik een wiskundige ben, en in de wiskunde is elke publicatie een samenvatting van stellingen en hun bewijzen. Daar iets publiceren zonder bewijs is een teken van slechte smaak. Als ik een bewering over de architectuur van de FS grondig bewijs of weerleg, zal het resultaat zulke stapels zijn dat het behoorlijk moeilijk zal zijn om er doorheen te komen. Wie heeft het nodig? Dit is waarschijnlijk de reden waarom alles in zijn oude vorm blijft: de broncode en het commentaar erop.
Wat is er de afgelopen jaren nieuw in Reiser4?
De langverwachte stabiliteit is eindelijk werkelijkheid geworden. Een van de laatste die opdook was een bug die leidde tot “niet-verwijderbare” mappen. De moeilijkheid was dat het alleen verscheen tegen de achtergrond van naam-hash-botsingen en met een bepaalde locatie van directoryrecords in een boomknooppunt. Voor productie kan ik Reiser4 echter nog steeds niet aanbevelen: hiervoor moet je wat werk verzetten met actieve interactie met productiesysteembeheerders.
We zijn er eindelijk in geslaagd ons al lang bestaande idee – verschillende transactiemodellen – te implementeren. Voorheen draaide Reiser4 slechts één hardgecodeerd Macdonald-Reiser-model. Dit zorgde voor ontwerpproblemen. In het bijzonder zijn snapshots niet mogelijk in een dergelijk transactioneel model - ze zullen worden beschadigd door een atomaire component genaamd “OVERWRITE SET”. Reiser4 ondersteunt momenteel drie transactiemodellen. In een daarvan (Write-Anywhere) bevat de atomaire component OVERWRITE SET alleen systeempagina's (afbeeldingen van schijfbitmaps, enz.), die niet kunnen worden “gefotografeerd” (het kip-en-ei-probleem).
De foto's kunnen nu dus op de best mogelijke manier worden gerealiseerd. In een ander transactioneel model gaan alle gewijzigde pagina's alleen naar de OVERWRITE SET (dat wil zeggen dat het in wezen pure journaling is). Dit model is bedoeld voor degenen die klaagden over de snelle fragmentatie van Reiser4-partities. In dit model zal uw partitie niet sneller fragmenteren dan met ReiserFS (v3). Alle drie de bestaande modellen garanderen, met enig voorbehoud, de atomiciteit van de operaties, maar modellen met verlies aan atomiciteit en waarbij alleen de integriteit van de sectie behouden blijft, kunnen ook nuttig zijn. Dergelijke modellen kunnen nuttig zijn voor allerlei soorten toepassingen (databases, enz.), die een aantal van deze functies al op zich hebben genomen. Het is heel gemakkelijk om deze modellen aan Reiser4 toe te voegen, maar ik heb het niet gedaan, omdat niemand het mij heeft gevraagd en ik het persoonlijk niet nodig heb.
Er verschenen controlesommen voor metadata en ik heb ze onlangs aangevuld met “economische” spiegels” (nog steeds onstabiel materiaal). Als de controlesom van een blok mislukt, leest Reiser4 onmiddellijk het overeenkomstige blok van het replica-apparaat. Merk op dat ZFS en Btrfs dit niet kunnen doen: het ontwerp staat dit niet toe. Daar moet u een speciaal achtergrondscanproces uitvoeren, genaamd "scrub", en wachten tot het bij het problematische blok komt. Programmeurs noemen dergelijke gebeurtenissen figuurlijk ‘krukken’.
En ten slotte zijn er heterogene logische volumes verschenen, die alles bieden wat ZFS, Btrfs, block layer en FS+LVM-combinaties in principe niet kunnen bieden: parallelle schaling, O(1) schijfadrestoewijzer, transparante datamigratie tussen subvolumes. Deze laatste heeft ook een gebruikersinterface. Nu kunt u eenvoudig de populairste gegevens naar de krachtigste schijf op uw volume verplaatsen.
Bovendien is het mogelijk om vervuilde pagina's dringend naar een dergelijke schijf te spoelen, waardoor toepassingen die vaak fsync(2) aanroepen aanzienlijk sneller worden. Ik merk op dat de bloklaagfunctionaliteit, bcache genaamd, helemaal niet zo'n vrijheid van handelen biedt. Nieuwe logische volumes zijn gebaseerd op mijn algoritmen (er zijn overeenkomstige patenten). De software is al behoorlijk stabiel, het is heel goed mogelijk om het te proberen, de prestaties te meten, enz. Het enige ongemak is dat je voorlopig de volumeconfiguratie handmatig moet bijwerken en ergens moet opslaan.
Tot nu toe heb ik mijn ideeën met 10 procent kunnen implementeren, maar ik ben erin geslaagd wat ik het moeilijkste vond: het verbinden van logische volumes met een flash-procedure die alle uitgestelde acties in reiser4 uitvoert. Dit bevindt zich allemaal nog in de experimentele “format41” -tak.
Voldoet Reiser4 aan de xfstests?
Dat gold tenminste voor mij toen ik de laatste release aan het voorbereiden was.
Is het in principe mogelijk om van Reiser4 een netwerk(cluster) FS te maken met behulp van plug-ins?
Het is mogelijk, en zelfs noodzakelijk! Als u een netwerkbestand maakt op basis van een goed ontworpen lokaal bestandssysteem, zal het resultaat zeer indrukwekkend zijn! In moderne netwerk-FS's ben ik niet tevreden met de aanwezigheid van een backend-opslagniveau, dat wordt geïmplementeerd met behulp van een lokale FS. Het bestaan van dit niveau is volkomen ongerechtvaardigd. De netwerk-FS moet rechtstreeks communiceren met de bloklaag en de lokale FS niet vragen om andere servicebestanden te maken!
Over het algemeen is het verdelen van bestandssystemen in lokaal en netwerk een kwade zaak. Het kwam voort uit de imperfectie van de algoritmen die dertig jaar geleden werden gebruikt, en waarvoor nog niets is voorgesteld. Dit is ook de reden voor het verschijnen van een massa onnodige softwarecomponenten (verschillende diensten, enz.). Op een goede manier zou er slechts één FS in de vorm van een kernelmodule en een set gebruikershulpprogramma's op elke machine geïnstalleerd moeten zijn: een clusterknooppunt. Deze FS is zowel lokaal als netwerk. En niets meer!
Als er niets lukt met Reiser4 op Linux, zou ik graag een FS voor FreeBSD willen aanbieden (citaat uit een eerder interview: “...FreeBSD... heeft academische wortels... En dit betekent dat we met een hoge mate van waarschijnlijkheid zal een gemeenschappelijke taal vinden met de ontwikkelaars”)?
Dus, zoals we net hebben ontdekt, is alles al perfect gelukt met Linux: er is een aparte werkende Reiser4-poort voor in de vorm van een masterbranch van onze repository. Ik ben FreeBSD niet vergeten! Aanbod! Ik ben bereid om nauw samen te werken met degenen die de binnenkant van FreeBSD goed kennen. Trouwens: wat ik erg leuk vind aan hun gemeenschap is dat de beslissingen daar worden genomen door een bijgewerkte raad van onafhankelijke deskundigen, wat niets te maken heeft met de misleiding van de overheid van één permanent persoon.
Hoe beoordeelt u de Linux-gebruikersgemeenschap vandaag? Is het meer “pop” geworden?
Gezien de aard van mijn werk is het voor mij lastig om dit te beoordelen. Meestal komen gebruikers naar mij toe met bugrapporten en verzoeken om de sectie te repareren. Gebruikers als gebruikers. Sommigen zijn verstandiger, anderen minder. Iedereen wordt hetzelfde behandeld. Welnu, als de gebruiker mijn instructies negeert, excuseer mij dan: het negeerbevel zal ook van mijn kant worden ingevoerd.
Is het mogelijk om de ontwikkeling van bestandssystemen voor de komende vijf tot tien jaar te voorspellen? Wat zijn volgens jou de belangrijkste uitdagingen waarmee FS-ontwikkelaars te maken kunnen krijgen?
Ja, het is niet moeilijk om zo'n voorspelling te doen. Er is al lange tijd geen ontwikkeling van bestandssystemen in de upstream. Alleen de schijn daarvan wordt gecreëerd. Ontwikkelaars van lokale bestandssystemen kwamen problemen tegen die verband hielden met een slecht ontwerp. Hier moet een kanttekening worden gemaakt. Ik beschouw het zogenaamde ‘opslaan’, ‘likken’ en porten van code niet als ontwikkeling en ontwikkeling. En ik classificeer het misverstand dat ‘Btrfs’ wordt genoemd niet als een ontwikkeling om de redenen die ik al heb uitgelegd.
Elke patch maakt de problemen alleen maar erger. Goed. en er zijn altijd verschillende soorten ‘evangelisten’ voor wie ‘alles werkt’. Kortom, dit zijn scholieren en studenten die colleges overslaan. Stel je voor: voor hem werkt het, maar voor de hoogleraar niet. Wat een adrenalinekick is dit! Vanuit mijn standpunt wordt de grootste schade veroorzaakt door de “vakmensen” die zich haastten om enthousiast de prachtige eigenschappen van Btrfs op allerlei lagen zoals systemd, docker, enz. te “schroeven”. - dit lijkt al op uitzaaiingen.
Laten we nu proberen een voorspelling te maken voor vijf tot tien jaar. Wat we gaan doen in Reiser4 heb ik al kort op een rijtje gezet. De belangrijkste uitdaging voor lokale FS-ontwikkelaars van upstream zal zijn (ja, dat is al zo geworden) het onvermogen om fatsoenlijk werk te doen voor een salaris. Zonder enig idee op het gebied van dataopslag zullen ze blijven proberen deze ongelukkige VFS, XFS en ext4 te patchen. Tegen deze achtergrond ziet de situatie met VFS er bijzonder komisch uit en doet denken aan de waanzinnige modernisering van een restaurant waarin geen chef-koks zijn en ook geen chef-koks worden verwacht.
Nu vergrendelt de VFS-code, zonder enige voorwaarden, meerdere geheugenpagina's tegelijkertijd en nodigt de onderliggende FS uit om ermee te werken. Dit werd geïntroduceerd om de prestaties van Ext4 bij verwijderbewerkingen te verbeteren, maar zoals gemakkelijk te begrijpen is, is een dergelijke gelijktijdige vergrendeling volledig incompatibel met geavanceerde transactiemodellen. Dat wil zeggen dat je niet zomaar ondersteuning voor een of ander slim bestandssysteem in de kernel kunt toevoegen. Ik weet niet hoe de situatie is op andere gebieden van Linux, maar wat de bestandssystemen betreft is het onwaarschijnlijk dat enige ontwikkeling hier verenigbaar zal zijn met het beleid dat Torvalds in de praktijk voert (academische projecten worden eruit gegooid en oplichters die heb geen idee wat een B-boom is, er worden eindeloze vertrouwenscredits uitgegeven). Daarom werd een koers uitgezet naar langzaam verval. Natuurlijk zullen ze uit alle macht proberen het voor te stellen als ‘ontwikkeling’.
Verder zullen de ‘bewaarders’ van bestandssystemen, die beseffen dat je met ‘opslag’ alleen niet veel zult verdienen, hun best doen om een winstgevender bedrijf op te zetten. Dit zijn in de regel gedistribueerde bestandssystemen en virtualisatie. Misschien zullen ze de modieuze ZFS ergens anders porten waar deze nog niet bestaat. Maar het lijkt, net als alle FS van stroomopwaarts, op een nieuwjaarsboom: als je er nog wat andere kleine dingen bovenop kunt hangen, dan kun je niet dieper komen. Ik geef toe dat het mogelijk is om een serieus bedrijfssysteem te bouwen op basis van ZFS, maar aangezien we nu over de toekomst praten, kan ik alleen maar helaas zeggen dat ZFS in dit opzicht hopeloos is: met hun virtuele apparaten hebben de jongens de zuurstof afgesloten voor zichzelf en toekomstige generaties voor verdere ontwikkeling. ZFS behoort tot het verleden. En ext4 en XFS zijn eergisteren niet eens.
Het is de moeite waard om apart te vermelden over het sensationele concept van het "Linux-bestandssysteem van de volgende generatie". Dit is een volledig politiek en marketingproject dat is gecreëerd met de mogelijkheid om, om zo te zeggen, “de toekomst van bestandssystemen” in Linux achter specifieke karakters te pinnen. Feit is dat Linux vroeger “gewoon voor de lol” was. Maar nu is het vooral een geldmachine. Ze zijn gemaakt op alles wat mogelijk is. Het is bijvoorbeeld heel moeilijk om een goed softwareproduct te maken, maar slimme ‘ontwikkelaars’ hebben zich al lang gerealiseerd dat er helemaal geen noodzaak is om te forceren: je kunt met succes niet-bestaande software verkopen die is aangekondigd en gepromoot bij allerlei soorten publiek. evenementen - het belangrijkste is dat de presentatiedia's meer "functies" moeten bevatten.
Bestandssystemen lenen zich hier uitstekend voor, omdat je gerust tien jaar lang kunt onderhandelen over het resultaat. Nou, als iemand later klaagt over het ontbreken van dit resultaat, dan begrijpt hij gewoon niets van bestandssystemen! Dit doet denken aan een financiële piramide: aan de top staan de avonturiers die deze puinhoop hebben veroorzaakt, en de weinigen die ‘geluk’ hadden: zij ‘hebben dividenden ingetrokken’, d.w.z. kreeg geld voor ontwikkeling, kreeg een goedbetaalde baan als manager, ‘verschijnde’ op conferenties, enz.
Vervolgens komen degenen die “pech” hebben: zij zullen verliezen tellen, omgaan met de gevolgen van het in productie nemen van een onbruikbaar softwareproduct, “enz. Er zijn er nog veel meer. Welnu, aan de basis van de piramide bevindt zich een enorme massa ontwikkelaars die nutteloze code ‘zagen’. Zij zijn de grootste verliezers, omdat verspilde tijd niet kan worden teruggegeven. Dergelijke piramides zijn buitengewoon gunstig voor Torvalds en zijn medewerkers. En hoe meer van deze piramides, hoe beter voor hen. Om zulke piramides te voeden kan alles in de kern worden gebracht. Natuurlijk zeggen ze in het openbaar het tegenovergestelde. Maar ik oordeel niet op woorden, maar op daden.
Dus “de toekomst van bestandssystemen in Linux” is wederom een sterk gepromote, maar nauwelijks bruikbare software. Na Btrfs zal met grote waarschijnlijkheid de plaats van een dergelijke “toekomst” worden ingenomen door Bcachefs, wat een nieuwe poging is om de Linux-bloklaag te doorkruisen met een bestandssysteem (een slecht voorbeeld is besmettelijk). En wat typisch is: er zijn dezelfde problemen als in Btrfs. Ik vermoedde dit al heel lang, en op de een of andere manier kon ik het niet laten en keek ik naar de code - het is waar!
De auteurs van Bcachefs en Btrfs hebben bij het maken van hun FS actief gebruik gemaakt van de bronnen van anderen en begrepen er weinig van. De situatie doet sterk denken aan het kinderspel 'kapote telefoon'. En ik kan me grofweg voorstellen hoe deze code in de kernel zal worden opgenomen. Eigenlijk zal niemand de “harken” zien (iedereen zal er later op stappen). Na talloze gezeur over de stijl van de code, beschuldigingen van niet-bestaande overtredingen, enz., Zal er een conclusie worden getrokken over de 'loyaliteit' van de auteur, hoe goed hij 'interageert' met andere ontwikkelaars, en hoe succesvol dit alles kan zijn vervolgens verkocht worden aan bedrijven.
Het eindresultaat zal niemand interesseren. Twintig jaar geleden zou ik misschien geïnteresseerd zijn geweest, maar nu worden de vragen anders gesteld: is het mogelijk om dit te bevorderen, zodat bepaalde mensen binnen de komende tien jaar een baan hebben? En helaas is het niet gebruikelijk om je af te vragen over het eindresultaat.
Over het algemeen raad ik u ten zeerste af om uw bestandssysteem helemaal opnieuw uit te vinden. Omdat zelfs aanzienlijke financiële investeringen niet voldoende zullen zijn om over tien jaar iets concurrerends te krijgen. Natuurlijk heb ik het over serieuze projecten, en niet over projecten die bedoeld zijn om in de kernel te worden “geduwd”. Een effectievere manier om jezelf te uiten is dus om je aan te sluiten bij echte ontwikkelingen, zoals wij. Dit is natuurlijk niet eenvoudig om te doen, maar dit is het geval bij elk project op hoog niveau.
Eerst moet je het probleem dat ik zal aanbieden zelfstandig overwinnen. Daarna zal ik, overtuigd van de ernst van uw bedoelingen, beginnen te helpen. Traditioneel gebruiken wij alleen onze eigen ontwikkelingen. De uitzonderingen zijn compressie-algoritmen en enkele hash-functies. We sturen geen ontwikkelaars om naar conferenties te reizen, en dan gaan we niet zitten en de ideeën van anderen combineren (“misschien gebeurt er wel”), zoals gebruikelijk is bij de meeste startups.
Wij ontwikkelen alle algoritmen zelf. Momenteel ben ik geïnteresseerd in de algebraïsche en combinatorische aspecten van de dataopslagwetenschap. In het bijzonder eindige velden, asymptotiek, bewijs van ongelijkheid. Er is ook werk voor gewone programmeurs, maar ik moet je meteen waarschuwen: alle suggesties om “naar een andere FS te kijken en hetzelfde te doen” worden genegeerd. Patches gericht op nauwere integratie met Linux via VFS zullen daar ook naartoe gaan.
We hebben dus geen duidelijk inzicht, maar we begrijpen wel waar we heen moeten, en we hebben er vertrouwen in dat deze richting de juiste is. Dit begrip kwam niet in de vorm van manna uit de hemel. Laat me je eraan herinneren dat we 29 jaar ontwikkelingservaring achter de rug hebben, twee bestandssystemen die helemaal opnieuw zijn geschreven. En hetzelfde aantal hulpprogramma's voor gegevensherstel. En dit is veel!
Bron: opennet.ru