Den zweeten Interview mam Eduard Shishkin, Entwéckler vum Reiser4 Dateiesystem, gouf publizéiert.
Fir unzefänken, erënnert w.e.g. d'Lieser wou a wien Dir schafft.
Ech schaffen als Principal Storage Architect bei Huawei Technologies, German Research Center. Am Virtualiséierungsdepartement beschäftegen ech mech mat verschiddenen Aspekter vum Datelagerung. Meng Aktivitéite sinn net mat engem spezifesche Betribssystem Zesummenhang.
Engagéiert Dir Iech de Moment fir d'Haaptkärnzweig?
Ganz selten, an nëmmen wann mäi Patron et verlaangt. Déi leschte Kéier war virun ongeféier dräi Joer, hunn ech Patches geschéckt fir den Duerchgang fir d'Späichere gedeelt op Hosten ze erhéijen, déi den 9p Protokoll benotzen (en aneren Numm fir dëst Geschäft ass VirtFS). Eng wichteg Notiz muss hei gemaach ginn: obwuel ech scho laang mat Linux geschafft hunn, war ech ni Fan dovun, dat heescht, ech "ootmen gläichméisseg", wéi mat alles anescht. Besonnesch wann ech e Feeler bemierken, kann ech et héchstens eemol opweisen. A fir datt Dir dann engem no kënnt an iwwerzeegen - dat wäert net geschéien.
Ech erënnere mech un d'lescht Kéier, virun zéng Joer, Dir waart zimlech kritesch zum Kernel Entwécklungsstil. Vun Ärer (oder vläicht Entreprise) Siicht, huet sech eppes geännert, ass d'Gemeinschaft méi reaktiounsfäeger ginn oder net? Wann net, wien mengt Dir ass Schold?
Ech hunn ni Ännerunge fir dat besser gesinn. Den Haaptproblem vun der Gemeinschaft ass den Ersatz vun der Wëssenschaft mat politeschen Technologien, perséinlech Bezéiungen, Majoritéit Meenung, Populismus, Rotschléi vun "bannenzege Stëmmen", verfault Kompromëss, alles anescht wéi Wëssenschaft. Informatik, wat ee seet, ass virun allem eng exakt Wëssenschaft. A wann een ufänkt säin eegene Wäert fir 2x2 ze proklaméieren, anescht wéi 4, ënner dem "Linux Way" Fändel, oder ënner engem anere Fändel, dann ass et onwahrscheinlech näischt anescht wéi Schued ze bréngen.
All Probleemer sinn haaptsächlech wéinst der Inkompetenz an dem Mangel un Ausbildung vun deenen, déi Entscheedungen treffen. Wann e Manager inkompetent ass, ass hien net fäeg eng objektiv, adäquat Entscheedung ze treffen. Wann hien och onkulturéiert ass, ass hien net fäeg e kompetente Spezialist ze fannen deen him déi richteg Berodung gëtt. Mat enger héijer Wahrscheinlechkeet wäert d'Wiel op e Scammer falen, deen "anscheinend richteg Saache" seet. E korrupt Ëmfeld entwéckelt sech ëmmer ronderëm inkompetent eenzege Leader. Ausserdeem kennt d'Geschicht keng Ausnahmen an deem Sënn, an d'Gemeng ass déi kloerst Bestätegung dovun.
Wéi bewäert Dir de Fortschrëtt an der Btrfs Entwécklung? Huet dës FS Kannerkrankheeten lass ginn? Wéi positionéiert Dir et fir Iech selwer - als FS "fir Heem" oder och fir Firmengebrauch?
Ech hunn et net lass ginn. Alles wat ech virun 11 Joer ernimmt hunn ass haut nach relevant. Ee vun de Probleemer mat Btrfs, déi et fir sérieux Bedierfnesser net gëeegent mécht, ass de Problem vum fräie Raum. Ech schwätzen net mol iwwer d'Tatsaach, datt de Benotzer gefrot gëtt, an de Buttek fir eng nei Scheif ze lafen an Situatiounen, wou all aner FS vill fräi Plaz op der Partition weisen. D'Onméiglechkeet eng Operatioun op engem logesche Volumen ze kompletéieren wéinst Mangel u fräi Plaz ass och net déi schlëmmst Saach. Dat Schlëmmst ass datt en onprivilegéierte Benotzer bal ëmmer all Diskquoten ëmgoe kann, jidderee fräi Plaz an enger relativ kuerzer Zäit entzéien.
Et gesäit esou aus (getest fir Linux Kernel 5.12). E Skript gëtt op engem frësch installéierten System lancéiert, deen an enger Loop Dateien mat bestëmmten Nimm am Heemverzeichnis erstellt, Donnéeën hinnen op bestëmmte Offsets schreift, an dann dës Dateien läscht. No enger Minutt vun dësem Skript lafen, geschitt näischt ongewéinlech. No fënnef Minutten ass den Deel vum besat Plaz op der Partition liicht erop. No zwou bis dräi Stonnen erreecht et 50% (mat engem initialen Wäert vun 15%). An no fënnef oder sechs Stonne vun der Aarbecht crasht de Skript mam Feeler "et gëtt keng fräi Plaz op der Partition." Duerno kënnt Dir net méi emol eng 4K Datei op Är Partition schreiwen.
Eng interessant Situatioun geschitt: Dir schlussendlech näischt op der Partition schreiwen, an all fräi Plaz (ongeféier 85%) verschwonnen iergendwou. Analyse vun enger Sektioun ënnerleien esou engem Attack wäert vill Bam Wirbelen opzeweisen nëmmen een Element (en Objet equipéiert mat engem Schlëssel), e puer Bytes an Gréisst. Dat ass, den Inhalt, dee virdru 15% vum Disk Space besat huet, huet sech als gläichméisseg "geschmiert" iwwer d'ganz Partition erausgestallt, sou datt et néierens ass fir eng nei Datei ze schreiwen, well säi Schlëssel méi grouss ass wéi all existent, an déi gratis. Blocken op der Partition sinn ausgaang.
Ausserdeem geschitt dëst alles schonn op der Basis Btrfs Konfiguratioun (ouni Schnappschëss, Ënnervolumen, etc.), an et ass egal wéi Dir décidéiert fir Dateikierper an deem FS ze späicheren (als "Fragmenter" an engem Bam, oder als Ausmooss vun onformatéierte Blocken) - d'Ennresultat wäert d'selwecht sinn.
Dir wäert net fäeg sinn aner Upstream Dateisystemer esou en Attack ze ënnerwerfen (egal wat se Iech soen). D'Ursaach vum Problem hunn ech viru laanger Zäit erkläert: dat ass eng komplett Perversioun vum B-Bam-Konzept an der Btrfs, déi et méiglech mécht datt et spontan oder bewosst degeneréiert. Besonnesch, ënner bestëmmte Lasten, wäert Äre Dateiesystem kontinuéierlech "auserneen falen" wärend der Operatioun eleng, ouni Hëllef vu baussen. Et ass kloer datt all Zorte vun "drécken" Hannergrondprozesser den Dag nëmmen op eenzel Desktops retten.
Op kollektive Serveren wäert en Ugräifer ëmmer fäeg sinn "viraus ze kommen". De Systemadministrator wäert net emol fäeg sinn erauszefannen, wien hien genee mobbéiert huet. De schnellste Wee fir dëse Problem an Btrfs ze fixéieren ass d'Struktur vun engem normale B-Bam ze restauréieren, d.h. den Diskformat nei designen an bedeitend Portiounen vum Btrfs Code nei schreiwen. Dëst wäert 8-10 Joer daueren, dorënner Debugging, virausgesat datt d'Entwéckler d'Originalartikelen iwwer déi relevant Algorithmen an Datenstrukturen strikt gefollegt hunn, an net de "gebrochenen Telefon" Spill gespillt hunn, wéi et üblech ass (an encouragéiert) am "Linux" Manéier".
Hei musse mir och d'Zäit addéieren fir d'Entwéckler dat alles ze verstoen. Dëst ass wou et méi schwéier gëtt. 10 Joer waren op alle Fall net genuch fir si ze verstoen. Gutt, bis dohinner kënnt Dir net op e Wonner hoffen. Et wäert net a Form vun enger Montéierungsoptioun geschéien "déi Dir an ech net wosst iwwer", oder a Form vun engem Patch deen "just eng Affär ass" ze preparéieren. Fir all sou séier "Fix" wäert ech en neie Szenario vun der Degeneratioun presentéieren. B-Beem sinn ee vu menge Liiblingsthemen, an ech muss soen datt dës Strukture keng Fräiheete mat sech selwer toleréieren!
Wéi positionéieren ech Btrfs fir mech? Als eppes wat absolut net e Dateiesystem kann genannt ginn, loosst eleng benotzt ginn. Well, per Definitioun, ass den FS en OS Subsystem verantwortlech fir déi effektiv Gestioun vun der "Disk Space" Ressource, déi mir net am Fall vu Btrfs gesinn. Gutt, stellt Iech vir datt Dir an de Buttek komm sidd fir eng Auer ze kafen fir net ze spéit op d'Aarbecht ze kommen, an amplaz vun enger Auer hunn se Iech en elektresche Grill mat Timer fir maximal 30 Minutten verkaaft. Also, d'Situatioun mat Btrfs ass nach méi schlëmm.
Wann ech duerch Mailinglëschte kucken, kommen ech dacks op d'Ausso datt d'Effizienz vun der Disk Space net méi relevant ass wéinst der bëlleger Fuerderung. Dëst ass komplett Nonsens. Ouni en effektiven Disk Space Manager gëtt den OS vulnérabel an onbrauchbar. Onofhängeg vun der Kapazitéit vun den Disken op Ärer Maschinn.
Ech wéilt e Kommentar iwwer d'Stéierung vun der Btrfs Ënnerstëtzung an der RHEL froen.
Et gëtt näischt Besonnesches hei ze kommentéieren, alles ass ganz kloer. Si haten et och als "Technologie Virschau". Also, ech sinn net duerch dës ganz "Virschau" gaang. Loosst dëse Label net fir ëmmer hänken! Awer si kënnen net e fehlerhafte By-Design Produkt mat voller Ënnerstëtzung starten. RHEL ass eng Entreprise, dat ass, verschriwwene Wueren-Suen Relatiounen. Red Hat kann d'Benotzer net mobben wéi se op der Btrfs Mailing Lëscht maachen. Stellt Iech just d'Situatioun vir: e Client, dee seng schwéier verdéngte Sue fir den Disk bezuelt huet an och Dir fir Ënnerstëtzung, wëll verstoen wou seng Disk Space higaang ass nodeems hien näischt opgeschriwwen huet. Wat wäert Dir him op dëser Äntwert?
Weider. Red Hat Clienten enthalen bekannte grouss Banken an Austausch. Stellt Iech vir wat géif geschéien wa se ënner DoS Attacken ënnerleien op Basis vun der genannter Schwachstelle bei Btrfs. Wien mengt Dir ass dofir verantwortlech? Fir déi, déi mam Fanger op d'Linn vun der GPL-Lizenz weisen, wou geschriwwen ass, datt den Auteur fir näischt verantwortlech ass, soen ech direkt: "Verstoppt et!" Red Hat wäert äntweren, an esou eng Manéier datt et net genuch schéngt! Awer ech weess datt de Red Hat net dës Zort vu Problem konfrontéiert ass, well hir besonnesch staark Team vu QA Ingenieuren mat deenen ech d'Méiglechkeet hat a menger Zäit enk ze schaffen.
Firwat ënnerstëtzen e puer Firmen weider Btrfs an hiren Enterprise Produkter?
Maacht weg datt de Präfix "Entreprise" am Produktnumm net vill bedeit. Enterprise ass eng Moossnam vu Verantwortung, déi an der kontraktueller Bezéiung mam Client agebonne sinn. Ech weess nëmmen eng Entreprise baséiert op GNU/Linux - RHEL. Alles anescht, aus menger Siicht, gëtt nëmmen als Entreprise presentéiert, awer ass net eng. A schliisslech, wann et eng Nofro fir eppes ass, da gëtt et ëmmer eng Versuergung (an eisem Fall ass dat déi ernimmt "Ënnerstëtzung"). Et gëtt Nofro fir absolut alles, inkl. an onbrauchbar Software. Wéi esou eng Demande geformt gëtt a wien se brennt ass en anert Thema.
Also, ech géif keng Conclusioune sprangen nodeems Facebook geruff gëtt Btrfs op seng Serveren ofgesat ze hunn. Ausserdeem géif ech recommandéieren d'Adresse vun deene Serveren aus den uewe genannte Grënn suergfälteg geheim ze halen.
Firwat ass sou vill Efforte gesat ginn fir den XFS Code ze botzen zënter kuerzem? No allem ass dëst am Ufank en Drëtt-Partei Dateiesystem, an ext4 ass laang stabil an huet Kontinuitéit vu fréiere gläich stabile Versiounen. Wéi eng Interessi huet Red Hat an XFS? Ass et Sënn fir aktiv zwee Dateiesystemer z'entwéckelen déi ähnlech am Zweck sinn - ext4 an XFS?
Ech erënnere mech net wat dëst motivéiert huet. Et ass ganz méiglech datt d'Initiativ vu Red Hat Cliente koum. Ech erënnere mech datt d'Fuerschung vun dëser Aart duerchgefouert gouf: op e puer Dateiesystemer vu Upstream goufen eng gigantesch Unzuel vun Objeten op High-End Drive vun der neier Generatioun erstallt. No de Resultater huet XFS sech besser behuelen wéi ext4. Also hunn se ugefaang et als déi villverspriechendst ze promoten. Ech géif op alle Fall näischt sensationelles hei sichen.
Fir mech ass et wéi wann se en Aal mat Seef ersat hunn. Et gëtt kee Sënn fir ext4 an XFS z'entwéckelen. Souwuel parallel an all vun hinnen aus ze wielen. Näischt Gutt wäert aus dësem kommen. Obwuel, an der Natur ginn et dacks Situatiounen, wou et vill Potenzial fir Wuesstem ass, awer et gëtt kee Raum fir ze wuessen. An dësem Fall entstinn verschidde komesch ellent nei Wuesstems, op déi jiddereen de Fanger weist ("Oh, kuckt, wat Dir an dësem Liewen net gesinn!").
Denkt Dir datt d'Fro vun der Layerverletzung geléist gouf (an engem negativen Sënn) mat der Advent vu Verschlësselungsfunktiounen an ext4, F2FS (net RAID an Btrfs ze ernimmen)?
Am Allgemengen ass d'Aféierung vun all Niveauen an eng Entscheedung iwwer hir Net-Verletzung normalerweis eng Fro vu Politik, an ech verpflichte näischt hei ze kommentéieren. Déi objektiv Aspekter vun der Schichtverletzung si vu wéineg Interesse fir jiddereen, awer mir kënnen e puer vun hinnen betruechten andeems Dir d'Beispill vun der Violatioun "vun uewen" benotzt, nämlech d'Ëmsetzung an der FS vun der Funktionalitéit déi schonn op der Blockschicht existéiert. Esou eng "Verletzung" ass mat nëmme rare Ausnahmen gerechtfäerdegt. Fir all esou Fall musst Dir éischt zwou Saache beweisen: datt et wierklech gebraucht gëtt, an datt den Design vum System net doduerch schued gëtt.
Zum Beispill, Spigelen, déi traditionell eng Aktivitéit fir d'Blockschicht war, mécht Sënn fir um Dateisystemniveau ëmzesetzen. Aus verschiddene Grënn. Zum Beispill, "roueg" Daten Korruptioun (Bit Rot) geschitt op Disk Drive. Dëst ass wann den Apparat richteg funktionnéiert, awer d'Blockdaten sinn onerwaart beschiedegt ënner dem Afloss vun engem haarde Gamma-Quante, dee vun engem wäitem Quasar emittéiert ass, etc. Dat Schlëmmst ass wann dëse Block e FS Systemblock (Superblock, Bitmap Block, Storage Bam Node, etc.) ass, well dëst wäert sécherlech zu enger Kernel Panik féieren.
Maacht weg datt d'Spigelen, déi vun der Blockschicht ugebuede ginn (sougenannte RAID 1) Iech net vun dësem Problem retten. Gutt, wierklech: iergendeen soll d'Kontrollsumme kontrolléieren an d'Replique am Fall vun Echec liesen? Ausserdeem mécht et Sënn fir net nëmmen alles ze spigelen, awer nëmmen d'Metadaten. E puer wichteg Donnéeën (zum Beispill ausführbar Dateie vu kriteschen Uwendungen) kënnen als Metadaten gespäichert ginn. An dësem Fall kréien se déiselwecht Sécherheetsgarantie. Et ass Sënn fir de Schutz vun de verbleiwen Donnéeën un aner Subsystemer (vläicht souguer Benotzerapplikatiounen) uvertraut - mir hunn all déi néideg Konditioune fir dëst geliwwert.
Esou "wirtschaftlech" Spigelen hunn e Recht ze existéieren, a si kënnen nëmmen effektiv um Dateisystemniveau organiséiert ginn. Soss ass d'Schichtverletzung e Subsystem mat duplizéierte Code zerstéiert fir e puer mikroskopesch Virdeeler. E markant Beispill vun dësem ass d'Ëmsetzung vun RAID-5 mat FS. Esou Léisungen (eegen RAID / LVM am Dateiesystem) ëmbréngen déi lescht am architektonesche Begrëff. Et sollt och hei bemierkt ginn datt d'Schichtverletzung "op Stream gesat gëtt" vu verschiddenen Aarte vu Marketing-Scammers. Beim Fehlen vun Iddien gëtt d'Funktionalitéit, déi laang op Nopeschniveauen ëmgesat gouf, an d'Subsystemer bäigefüügt, dëst gëtt als eng nei extrem nëtzlech Feature presentéiert a gëtt aktiv gedréckt.
De Reiser4 gouf virgeworf, d'Niveauen "vun ënnen" ze verletzen. Baséierend op der Tatsaach, datt de Dateiesystem net monolithesch ass, wéi all déi aner, awer modulär, gouf eng onbestänneg Viraussetzung gemaach datt et mécht wat den Niveau uewen (VFS) soll maachen.
Ass et méiglech iwwer den Doud vu ReiserFS v3.6 an zum Beispill JFS ze schwätzen? A leschter Zäit hu se bal keng Opmierksamkeet am Kär kritt. Sinn se obsolet?
Hei musse mir definéieren wat den Doud vun engem Softwareprodukt bedeit. Engersäits gi se erfollegräich benotzt (dat ass wat se erstallt hunn, schliisslech), dat heescht datt se liewen. Op der anerer Säit kann ech net fir JFS schwätzen (ech weess net vill), awer ReiserFS (v3) ass ganz schwéier un nei Trends unzepassen (an der Praxis getest). Dëst bedeit datt d'Entwéckler an Zukunft net op et oppassen, awer op déi, déi méi einfach unzepassen. Vun dëser Säit stellt sech eraus, datt et leider am architektonesche Begrëff dout ass. Ech géif d'Konzept vun "moralesch verouderte" iwwerhaapt net manipuléieren. Et gëlt gutt, zum Beispill, fir e Kleederschaf, awer net fir Softwareprodukter. Et gëtt e Konzept vun Ënneruerdnung an Iwwerleeënheet an eppes. Ech kann absolut soen datt de ReserFS v3 elo méi schlecht ass wéi de Reiser4 an allem, awer an e puer Aarte vun Aarbechtsbelaaschtung ass et besser wéi all aner Upstream FSs.
Wësst Dir iwwer d'Entwécklung vun FS Tux3 an HAMMER / HAMMER2 (FS fir DragonFly BSD)?
Jo, mir wëssen. Am Tux3 war ech emol interesséiert fir d'Technologie vun hire Schnappschëss (déi sougenannte "Versiounspointer"), awer bei Reiser4 wäerte mir héchstwahrscheinlech en anere Wee goen. Ech hu scho laang dru geduecht fir Snapshots z'ënnerstëtzen an hunn nach net decidéiert wéi se se fir einfache Reiser4 Bänn ëmsetzen. D'Tatsaach ass, datt déi nei "faul" Referenz Konter Technik proposéiert vum Ohad Rodeh nëmme fir B-Beem Wierker. Mir hunn se net. Fir déi Datenstrukturen, déi am Reiesr4 benotzt ginn, sinn "faul" Zähler net definéiert - fir se anzeféieren ass et néideg fir verschidde algorithmesch Probleemer ze léisen, déi nach keen ugeholl huet.
Laut HAMMER: Ech liesen en Artikel vum Créateur. Net interesseiert. Nach eng Kéier, B-Beem. Dës Datestruktur ass hoffnungslos verännert. Mir hunn et am leschte Joerhonnert opginn.
Wéi bewäert Dir déi wuessend Nofro fir Netzwierkcluster FSs wéi CephFS / GlusterFS / etc? Heescht dës Nofro eng Verréckelung vun de Prioritéite vun Entwéckler Richtung Reseau FS an net genuch Opmierksamkeet op lokal FS?
Jo, esou eng Prioritéitverrécklung ass geschitt. D'Entwécklung vu lokalen Dateiesystemer ass stagnéiert. Ee, eppes bedeitendst fir lokal Bänn maachen ass elo relativ schwéier an net jiddereen kann et maachen. Keen wëll an hir Entwécklung investéieren. Dëst ass ongeféier d'selwecht wéi eng kommerziell Organisatioun ze froen fir Sue fir mathematesch Fuerschung ze verdeelen - ouni Begeeschterung wäerte se Iech froen wéi Dir Sue mat engem neien Theorem maache kënnt. Elo ass e lokalen FS eppes wat magesch "aus der Këscht" erschéngt a "soll ëmmer funktionnéieren", a wann et net funktionnéiert, verursaacht et onadressert Grommel wéi: "Jo, wat denken se!"
Dofir de Mangel un Opmierksamkeet op lokal FS, obwuel et nach vill Aarbecht an deem Beräich ass. A jo, jiddereen huet sech op verdeelt Späichere gedréint, déi op der Basis vu scho existéierende lokalen Dateisystemer gebaut ass. Et ass elo ganz moudesch. Den Ausdrock "Big Data" verursaacht en Adrenalinrush fir vill, associéiert et mat Konferenzen, Workshops, grouss Paien, asw.
Wéi raisonnabel ass et am Prinzip den Netzwierkdateisystem am Kernelraum ëmzesetzen anstatt am Benotzerraum?
Eng ganz raisonnabel Approche déi nach néierens ëmgesat gouf. Am Allgemengen ass d'Fro, a wéi engem Raum e Netzwierkdateisystem soll ëmgesat ginn, ass en "duebelschneidegt Schwäert." Gutt, loosst eis e Beispill kucken. De Client huet Daten op enger Fernmaschinn opgeholl. Si gefall an hirem Säit Cache a Form vun dreckeg Säiten. Dëst ass d'Aarbecht fir en "dënnen Paart" Netzwierkdateisystem am Kernelraum. Da freet de Betribssystem Iech fréier oder spéider dës Säiten op Disk ze schreiwen fir se ze befreien. Da kënnt den IO-Forwarding (Send) Netzwierk FS Modul an d'Spill. Et bestëmmt op wéi eng Servermaschinn (Servernode) dës Säite goen.
Dann iwwerhëlt den Netzwierkstack (a wéi mir wëssen, ass et am Kernelraum ëmgesat). Als nächst kritt de Servernode dëse Paket mat Daten oder Metadaten an instruéiert de Backend-Späichermodul (dh de lokalen FS deen am Kernelraum funktionnéiert) fir all dës Saachen opzehuelen. Also, mir hunn d'Fro reduzéiert op wou d'Module "Schécken" an "Empfang" solle funktionnéieren. Wann ee vun dëse Moduler am Benotzerraum lafen, wäert dëst zwangsleefeg zu Kontextwiessel féieren (wéinst der Bedierfnes fir Kernelservicer ze benotzen). D'Zuel vun esou Schalter hänkt vun den Ëmsetzungsdetailer of.
Wann et vill esou Schalter sinn, da wäert d'Späicherduerchgang (I / O Leeschtung) erofgoen. Wann Är Backend-Speicher aus luesen Disken besteet, da mierkt Dir net e wesentleche Réckgang. Awer wann Dir séier Disken hutt (SSD, NVRAM, etc.), da gëtt Kontextschaltung schonn e "Flaschenhals" an, andeems Dir op Kontextwiessel spuert, kann d'Performance wesentlech erhéicht ginn. De Standard Wee fir Suen ze spueren ass Moduler an de Kernelraum ze réckelen. Zum Beispill hu mir festgestallt datt d'Bewegung vum 9p-Server vu QEMU op de Kernel op der Hostmaschinn zu enger dräifach Erhéijung vun der VirtFS-Performance féiert.
Dëst ass natierlech keen Netz FS, awer et reflektéiert voll d'Essenz vun de Saachen. Den Nodeel vun dëser Optimiséierung ass Portabilitéitsprobleemer. Fir e puer kann déi lescht kritesch sinn. Zum Beispill, GlusterFS huet guer keng Moduler am Kernel. Dank dësem funktionnéiert et elo op ville Plattformen, dorënner NetBSD.
Wéi eng Konzepter kéinte lokal FSs aus Netzwierker léinen a vice versa?
Hautdesdaags hunn Netzwierk FSs, als Regel, Add-ons iwwer lokal FSs, also verstinn ech net ganz wéi Dir eppes vun der leschter léine kënnt. Majo, loosst eis eng Firma vu 4 Mataarbechter betruechten, an där jidderee seng Saach mécht: deen een verdeelt, deen aneren schéckt, deen Drëtte kritt, deen véierte Geschäfter. An d'Fro, wat kann d'Firma vu sengem Employé léinen, deen et späichert, kléngt iergendwéi falsch (et huet scho wat se vun him fir eng laang Zäit geléint hätt).
Awer lokal FSs hu vill vun Netzwierker ze léieren. Als éischt sollt Dir vun hinnen léieren wéi Dir logesch Bänn op engem héijen Niveau aggregéiert. Elo de sougenannte "fortgeschratt" lokal Dateisystemer aggregéiere logesch Bänn exklusiv mat "virtuellen Apparat" Technologie geléint vu LVM (déi selwecht infektiiv Schichtenverletzung déi fir d'éischt an ZFS ëmgesat gouf). An anere Wierder, Iwwersetzung vu virtuelle Adressen (Blocknummeren) an realen an zréck geschitt op engem nidderegen Niveau (dh nodeems de Dateiesystem eng I / O Ufro erausginn huet).
Notéiert w.e.g. datt d'Addéieren an d'Ewechhuele vu Geräter op logesch Bänn (net Spigelen) op der Blockschicht arrangéiert féiert zu Probleemer, déi d'Liwweranten vun esou "Features" bescheiden roueg sinn. Ech schwätzen iwwer Fragmentatioun op realen Apparater, déi monstréis Wäerter erreechen kënnen, während op engem virtuellen Apparat alles gutt ass. Wéi och ëmmer, wéineg Leit sinn un virtuellen Apparater interesséiert: jiddereen ass interesséiert wat op Äre richtegen Apparater geschitt. Awer ZFS-ähnlech FS (wéi och all FS a Verbindung mat LVM) funktionnéieren nëmme mat virtuelle Scheif-Geräter (virtuell Scheif Adressen aus tëscht fräien, defragmentéieren dës virtuell Apparater, etc.). A si hu keng Ahnung wat op realen Apparater geschitt!
Stellt Iech elo vir, datt Dir null Fragmentatioun op der virtueller Apparat hutt (dat ass, Dir hutt just e riesegen Ausmooss do wunnen), Dir füügt eng Scheif op Är logesch Volumen, a läscht dann eng aner zoufälleg Scheif aus Ärem logesche Volumen an dann rebalance. An esou vill Mol. Et ass net schwéier virzestellen datt Dir op dem virtuellen Apparat nach ëmmer dee selwechte Liewensraum hutt, awer op realen Apparater gesitt Dir näischt Gutt.
Dat Schlëmmst ass datt Dir dës Situatioun net emol korrigéiere kënnt! Dat eenzegt wat Dir hei maache kënnt ass de Dateiesystem ze froen fir de virtuellen Apparat ze defragmentéieren. Awer hatt wäert Iech soen datt alles super do ass - et gëtt nëmmen een Ausmooss, d'Fragmentatioun ass null, an et kann net besser sinn! Also logesch Bänn, déi um Blockniveau arrangéiert sinn, sinn net fir widderholl Zousatz / Entfernung vun Apparater geduecht. Op eng gutt Manéier braucht Dir nëmmen e logesche Volumen um Blockniveau eemol ze sammelen, et dem Dateiesystem ze ginn, an dann näischt anescht ze maachen.
Zousätzlech erlaabt d'Kombinatioun vun onofhängege FS + LVM-Ënnersystemer eis net déi ënnerschiddlech Natur vun den Drive ze berücksichtegen, aus deenen logesch Bänn aggregéiert sinn. Tatsächlech, ugeholl datt Dir e logesche Volume vun HDD a Solid-State Geräter zesummegesat hutt. Awer dann erfuerdert déi fréier Defragmentatioun, an déi lescht net. Fir déi lescht musst Dir Ufroen ofginn, awer fir déi fréier, net, etc. Wéi och ëmmer, an dëser Kombinatioun ass et zimlech schwéier sou Selektivitéit ze weisen.
Bedenkt datt nodeems Dir Ären eegene LVM am Dateiesystem erstallt hutt, gëtt d'Situatioun net vill besser. Ausserdeem, andeems Dir dëst maacht, setzt Dir tatsächlech en Enn fir d'Perspektiv et an Zukunft ëmmer ze verbesseren. Dëst ass ganz schlecht. Verschidden Zorte vun fiert kann op der selwechter Maschinn liewen. A wann de Dateiesystem net tëscht hinnen ënnerscheet, wien dann?
En anere Problem läit op de sougenannten. "Write-Anywhere" Dateisystemer (dëst enthält och Reiser4, wann Dir de passenden Transaktiounsmodell während der Montéierung uginn hutt). Esou Dateiesystemer mussen Defragmentatiounsinstrumenter ubidden, déi onendlech an hirer Kraaft sinn. An de Low-Level Volume Manager hëlleft hei net, mee just am Wee. D'Tatsaach ass datt mat sou engem Manager Äre FS eng Kaart vu gratis Blocks vun nëmmen engem Apparat späichert - e virtuelle. Deementspriechend kënnt Dir nëmmen e virtuellen Apparat defragmentéieren. Dëst bedeit datt Ären Defragmenter fir eng laang, laang Zäit op engem risegen eenzege Raum vu virtuelle Adressen funktionnéiert.
A wann Dir vill Benotzer hutt, déi zoufälleg Iwwerschreiwe maachen, da gëtt den nëtzlechen Effekt vun esou engem Defragmenter op Null reduzéiert. Äre System wäert zwangsleefeg ufänken ze luesen, an Dir musst nëmmen Är Hänn virun der enttäuschenden Diagnos "gebrach Design" falen. Verschidde Defragmenter, déi um selwechten Adressraum lafen, stéieren nëmme mateneen. Et ass eng komplett aner Saach wann Dir Är eege Kaart vu gratis Blocks fir all richtegt Apparat behält. Dëst wäert effektiv den Defragmentatiounsprozess paralleliséieren.
Awer dëst kann nëmme gemaach ginn wann Dir e logesche Volume Manager op héijem Niveau hutt. Lokal Dateisystemer mat esou Manager existéieren net virdru (op d'mannst, ech weess net iwwer si). Nëmmen Netzwierk Dateisystemer (zum Beispill GlusterFS) haten esou Manager. En anert ganz wichtegt Beispill ass de Volume Integrity Check (fsck) Utility. Wann Dir Är eege onofhängeg Kaart vu gratis Blocks fir all Ënnervolumen späichert, da kann d'Prozedur fir e logesche Volumen ze kontrolléieren effektiv paralleliséiert ginn. An anere Wierder, logesch Bänn mat héije Manager Skala besser.
Zousätzlech, mat Low-Level Volume Manager kënnt Dir net vollwäerteg Snapshots organiséieren. Mat LVM an ZFS-ähnlechen Dateiesystemer kënnt Dir nëmmen lokal Schnappschëss huelen, awer net global Schnappschëss. Lokal Snapshots erlaaben Iech direkt nëmme regelméisseg Dateioperatiounen zréckzerollen. A keen do wäert d'Operatiounen mat logesche Bänn zréckrollen (addéieren / ewechhuelen Apparater). Loosst eis dëst mat engem Beispill kucken. Irgendwann an der Zäit, wann Dir e logesche Volume vun zwee Apparater A a B mat 100 Dateien hutt, maacht Dir e Snapshot vum System S an erstellt dann eng aner honnert Dateien.
Duerno füügt Dir den Apparat C op Äre Volumen, a schliisslech rollback Äre System op Snapshot S. Fro: Wéivill Dateien an Apparater enthält Äre logesche Volume no der Rollback op S? Et wäerten 100 Dateien sinn, wéi Dir vläicht scho virgestallt hutt, awer et wäerten 3 Apparater sinn - dat sinn déiselwecht Apparater A, B a C, och wann de Moment wou de Snapshot erstallt gouf, waren et nëmmen zwee Apparater am System (A a B) ). D'Add-Apparat C Operatioun ass net zréckgeréckelt, a wann Dir elo den Apparat C vum Computer läscht, wäert et Är Donnéeën korruptéieren, also ier Dir läscht musst Dir als éischt eng deier Operatioun ausféieren fir den Apparat aus dem logesche Volumen ze läschen, wat wäert all d'Donnéeën aus Apparat C ze Apparater A an B Streuen. Mä wann Är FS global Schnappschëss ënnerstëtzt, esou rebalancing wier net néideg, an no engem Direktnoriichten rollback zu S, Dir kënnt sécher Apparat C aus dem Computer ewechzehuelen.
Also, global Snapshots si gutt, well se Iech erlaben d'deier Entfernung (Zousätzlech) vun engem Apparat aus engem logesche Volume (zu engem logesche Volume) mat enger grousser Quantitéit un Daten ze vermeiden (natierlech, wann Dir Iech drun erënnert Äre System ze "Snapshot" zu der richteger Zäit). Loosst mech Iech drun erënneren datt Snapshots erstellen an de Dateiesystem op si zréckrollen, sinn direkt Operatiounen. D'Fro kann opstoen: Wéi ass et iwwerhaapt méiglech eng Operatioun op engem logesche Volumen direkt zréckzekréien, deen Iech dräi Deeg gedauert huet? Awer et ass méiglech! Virausgesat datt Äre Dateiesystem richteg entworf ass. Ech sinn virun dräi Joer op d'Iddi vun esou "3D Schnappschëss" komm, an d'lescht Joer hunn ech dës Technik patentéiert.
Déi nächst Saach, déi lokal FSs aus dem Netzwierk léiere solle, ass d'Metadaten op getrennten Apparater ze späicheren op déiselwecht Manéier wéi d'Netz-FSs se op getrennte Maschinnen späicheren (de sougenannte Metadatenserver). Et gi Applikatiounen déi haaptsächlech mat Metadaten funktionnéieren, an dës Applikatioune kënne staark beschleunegt ginn andeems d'Metadaten op deier héich performant Späichergeräter plazéiert ginn. Mat der FS + LVM Kombinatioun, kënnt Dir net esou Selektivitéit weisen: LVM weess net wat op de Block ass, deen Dir un et passéiert (Daten do oder Metadaten).
Dir kritt net vill Benefice vun Ärem eegene Low-Level LVM an der FS ëmzesetzen am Verglach mat der FS + LVM Kombinatioun, awer wat Dir ganz gutt maache kënnt ass de FS ze räissen sou datt et spéider onméiglech gëtt mat sengem Code ze schaffen. ZFS an Btrfs, déi mat virtuellen Apparater gerannt sinn, sinn all kloer Beispiller vu wéi d'Schichtverletzung de System an architektonesche Begrëffer ëmbréngt. Also, firwat sinn ech dat alles? Ausserdeem ass et net néideg Ären eegene Low-Level LVM am Dateiesystem ze bauen. Amplaz musst Dir Apparater a logesch Bänn op engem héijen Niveau aggregéieren, wéi e puer Netzwierkdateiesystemer mat verschiddene Maschinnen (Späichernoden) maachen. Richteg, si maachen dat Eekleges wéinst der Benotzung vu schlechten Algorithmen.
Beispiller vun absolut schrecklechen Algorithmen sinn den DHT Iwwersetzer am GlusterFS Dateiesystem an déi sougenannte CRUSH Kaart am Ceph Dateiesystem. Keen vun den Algorithmen déi ech gesinn hunn hunn mech zefridden a punkto Einfachheet a gudder Skalierbarkeet. Also hunn ech d'Algebra missen erënneren an alles selwer erfannen. Am Joer 2015, wärend ech experimentéiert mat Bündel iwwer Hashfunktiounen, hunn ech eppes erauskomm an patentéiere wat mir passt. Elo kann ech soen datt de Versuch dëst alles an der Praxis ëmzesetzen erfollegräich war. Ech gesinn keng Probleemer mat Skalierbarkeet an der neier Approche.
Jo, all Ënnervolumen erfuerdert eng separat Struktur wéi e Superblock an der Erënnerung. Ass dëst ganz grujeleg? Am Allgemengen weess ech net wien "den Ozean kachen" a logesch Bänn vun honnertdausende oder méi Apparater op enger lokaler Maschinn erstellen. Wann iergendeen mir dat erkläre kann, wäert ech ganz dankbar sinn. An der Tëschenzäit ass dat fir mech Marketing Bullshit.
Wéi hunn d'Ännerungen am Kernel Block Apparat Subsystem (zum Beispill d'Erscheinung vu blk-mq) d'Ufuerderunge fir d'FS Implementatioun beaflosst?
Si haten keen Impakt. Ech weess net wat op der Spär Layer geschéie géif, datt et néideg maachen eng nei FS ze Design. D'Interaktiounsinterface vun dësen Ënnersystemer ass ganz schlecht. Vun der Chauffeur Säit soll de FS nëmmen duerch d'Erscheinung vun neien Typen vun Drive beaflosst ginn, op déi d'Blockschicht als éischt ugepasst gëtt, an dann den FS (fir reiser4 heescht dat d'Erscheinung vun neie Plugins).
Heescht d'Entstoe vun neien Typen vu Medien (zum Beispill SMR, oder d'Ubiquity vun SSDs) grondsätzlech nei Erausfuerderunge fir Dateiesystemdesign?
Jo. An dës sinn normal Ureizer fir d'Entwécklung vun FS. Erausfuerderunge kënnen ënnerschiddlech a komplett onerwaart sinn. Zum Beispill hunn ech vun Drive héieren wou d'Geschwindegkeet vun enger I/O Operatioun héich ofhängeg vun der Gréisst vun engem Stéck Daten a seng Offset ass. Am Linux, wou d'Gréisst vum FS-Block d'Säitgréisst däerf net iwwerschreiden, weist esou en Drive net seng voll Fäegkeeten als Standard. Wéi och ëmmer, wann Äre Dateiesystem richteg entworf ass, da gëtt et eng Chance fir vill méi dovun ze kréien.
Wéi vill Leit schaffen am Moment nieft Iech mam Reiser4 Code?
Manner wéi ech gär hätt, mee ech erliewen och keen akuten Mangel u Ressourcen. Ech si méi wéi zefridde mam Tempo vun der Entwécklung vu Reiser4. Ech wäert net "Päerd fueren" - dëst ass net dat richtegt Gebitt. Hei, "wann Dir méi roueg fuert, gitt Dir weider!" E modernen Dateiesystem ass dee komplexste Kernel-Subsystem, déi falsch Designdecisioune vun deenen déi spéider Jore vu mënschlecher Aarbecht réckgängeg maachen.
Andeems ech de Fräiwëlleger ubidden fir eppes ëmzesetzen, garantéieren ech ëmmer datt d'Efforte sécherlech zum richtege Resultat féieren, wat fir sérieux Bedierfnesser gefuerdert ka sinn. Wéi Dir verstitt, kann et net vill esou Garantien op eemol ginn. Zur selwechter Zäit kann ech net "Figuren" ausstoen, déi schuedlos "Features" vun offensichtlech onbenotzbarer Software förderen, Honnerte vu Benotzer an Entwéckler täuschen, a gläichzäiteg op Kernel Sommets sëtzen a laachen.
Huet eng Firma de Bereetschaft ausgedréckt fir d'Entwécklung vu Reiser4 z'ënnerstëtzen?
Jo, et goufen esou Propositiounen, inkl. a vun engem grousse Verkeefer. Mee dofir hunn ech missen an en anert Land plënneren. Leider sinn ech net méi 30 Joer aal, ech kann net briechen a sou op der éischter Pfeift verloossen.
Wéi eng Fonctiounen feelen am Moment vum Reiser4?
Et gëtt keng "Gréisst änneren" Funktioun fir einfach Bänn, ähnlech wéi déi am ReiserFS (v3) fonnt. Zousätzlech wäerte Dateioperatioune mam DIRECT_IO Fändel net verletzen. Als nächst géif ech fäeg sinn e Volume an "semantesch Ënnervolumen" ze trennen, déi keng fix Gréisst hunn, an déi als onofhängeg Volumen montéiert kënne ginn. Dës Probleemer si gutt fir Ufänger, déi hir Hand an der "echter Saach" probéieren wëllen.
A schlussendlech wéilt ech Netzwierk logesch Bänn mat einfacher Ëmsetzung an Administratioun hunn (modern Algorithmen erlaben dat schonn). Awer wat de Reiser4 definitiv ni wäert hunn ass RAID-Z, Scrubs, Fräiraum-Cache, 128-Bit Variabelen an aner Marketing-Blëtz, déi géint den Hannergrond vun engem Mangel un Iddien ënner den Entwéckler vun e puer Dateisystemer entstane sinn.
Kann alles wat néideg ass duerch Plugins ëmgesat ginn?
Wa mir nëmme vu Schnëttplazen a Plugins (Module) schwätzen, déi se ëmsetzen, dann net alles. Awer wann Dir och Bezéiungen op dësen Schnëttplazen aféieren, da wäert Dir ënner anerem d'Konzepter vu méi héije Polymorphismen hunn, mat deenen Dir scho ka kommen. Stellt Iech vir datt Dir hypothetesch en objektorientéierte Runtime System gefruer hutt, de Wäert vum Instruktiounspointer geännert huet fir op en anere Plugin ze weisen deen déiselwecht X Interface implementéiert, an dann de System unfrost fir datt et weider geet.
Wann den Endbenotzer sou eng "Substitutioun" net bemierkt, da soen mir datt de System Nullorder Polymorphismus an der X Interface huet (oder de System ass heterogen an der X Interface, dat ass datselwecht). Wann Dir elo net nëmmen eng Rei vu Schnëttplazen hutt, awer och Bezéiungen op hinnen hunn (Interface Grafik), da kënnt Dir Polymorphismen vu méi héijen Uerderen aféieren, déi d'Heterogenitéit vum System schonn an der "Noperschaft" vun all Interface charakteriséieren. Ech hunn esou eng Klassifikatioun viru laanger Zäit agefouert, awer leider ass et ni geschitt.
Also, mat der Hëllef vu Plugins an esou méi héije Polymorphismen, kënnt Dir all bekannt Feature beschreiwen, wéi och déi "virauszesoen", déi nach ni ernimmt goufen. Ech konnt dat net strikt beweisen, mee ech weess och nach kee Géigebeispill. Allgemeng huet dës Fro un dem Felix Klein säi "Erlangen Programm" erënnert. Eng Kéier huet hien probéiert all Geometrie als Filial vun der Algebra ze representéieren (speziell Gruppentheorie).
Elo zur Haaptfro - wéi geet et mat der Promotioun vum Reiser4 an den Haaptkär? Ginn et Publikatiounen iwwer d'Architektur vun dësem Dateiesystem iwwer déi Dir am leschten Interview geschwat hutt? Wéi relevant ass dës Fro aus Ärer Siicht?
Am Allgemengen froe mir zënter dräi Joer eng Inklusioun an der Haaptbranche. Dem Reiser säi leschte Kommentar am ëffentleche Fuedem, wou d'Pull-Ufro gemaach gouf, blouf onbeäntwert. Also all weider Froen sinn net fir eis. Ech perséinlech verstinn net firwat mir mussen an e spezifesche Betribssystem "fusionéieren". Op Linux huet d'Liicht net wéi e Keil konvergéiert. Also, et gëtt e separaten Repository an deem et e puer Branche-Ports fir verschidden OSe gëtt. Wien et brauch, kann den entspriechende Hafen klonen a maache wat Dir wëllt mat him (natierlech bannent der Lizenz). Gutt, wann een et net brauch, dann ass et net mäi Problem. Zu dësem Zäitpunkt proposéieren ech d'Fro vun der "Promotioun an den Haapt Linux Kernel" ze berécksiichtegen wéi geléist.
Publikatiounen iwwer FS Architektur sinn relevant, mee bis elo hunn ech nëmmen Zäit fonnt fir meng nei Resultater, déi ech als eng méi héich Prioritéit betruechten. Eng aner Saach ass datt ech e Mathematiker sinn, an an der Mathematik ass all Publikatioun e Resumé vun Theorem an hir Beweiser. Alles do ze verëffentlechen ouni Beweis ass en Zeeche vu schlechtem Goût. Wann ech eng Ausso iwwer d'Architektur vum FS grëndlech beweisen oder widderleen, da wäert d'Resultat esou Koupe sinn, datt et zimmlech schwéier wäert duerchzekommen. Wien brauch et? Dëst ass wahrscheinlech firwat alles weider a senger aler Form bleift - de Quellcode an d'Kommentaren derzou.
Wat ass an de leschte Joren nei zu Reiser4?
Déi laang erwaarde Stabilitéit ass endlech materialiséiert. Ee vun de leschten ze erschéngen war e Feeler deen zu "ondeleteable" Verzeichnisser gefouert huet. D'Schwieregkeet war datt et nëmmen géint den Hannergrond vun Numm Hash Kollisiounen a mat enger bestëmmter Plaz vun Verzeechnes records an engem Bam Node erschéngt. Wéi och ëmmer, ech kann de Reiser4 net fir d'Produktioun recommandéieren: dofir musst Dir eng Aarbecht mat enger aktiver Interaktioun mat Produktiounssystemadministratoren maachen.
Mir hunn et endlech fäerdeg bruecht eis laangjäreg Iddi ëmzesetzen - verschidde Transaktiounsmodeller. Virdrun huet Reiser4 nëmmen een hardcoded Macdonald-Reiser Modell gefuer. Dëst huet Designproblemer erstallt. Besonnesch Snapshots sinn net méiglech an esou engem Transaktiounsmodell - si ginn duerch eng atomar Komponent genannt "OVERWRITE SET" korrupt. Reiser4 ënnerstëtzt de Moment dräi Transaktiounsmodeller. An engem vun hinnen (Write-Anywhere) enthält den Atomkomponent OVERWRITE SET nëmmen System Säiten (Biller vun Scheif Bitmaps, etc.), déi net "fotograféiert" kënne ginn (de Poulet an Ee Problem).
Also kënnen d'Biller elo am beschten realiséiert ginn. An engem aneren Transaktiounsmodell ginn all modifizéiert Säiten nëmmen op den OVERWRITE SET (dat ass, et ass am Wesentlechen pure Journaling). Dëse Modell ass fir déi, déi sech iwwer déi séier Fragmentatioun vu Reiser4 Partitionen beschwéiert hunn. Elo an dësem Modell wäert Är Partition net méi séier fragmentéieren wéi mat ReiserFS (v3). All dräi existent Modeller, mat e puer Reservatiounen, garantéieren d'Atomizitéit vun Operatiounen, awer Modeller mat Atomkraaftverloscht an nëmmen d'Integritéit vun der Sektioun erhalen kënnen och nëtzlech sinn. Esou Modeller kënnen nëtzlech sinn fir all Zorte vun Uwendungen (Datenbanken, asw.), déi schonn e puer vun dëse Funktiounen iwwerholl hunn. Et ass ganz einfach dës Modeller op Reiser4 ze addéieren, awer ech hunn et net gemaach, well keen mech gefrot huet, an ech perséinlech brauch et net.
Metadatenchecksummen erschéngen an ech hunn se viru kuerzem mat "wirtschaftlechen" Spigelen ergänzt (nach ëmmer onbestänneg Material). Wann d'Kontrollsum vun engem Block klappt, liest Reiser4 direkt de entspriechende Block aus dem Replica-Apparat. Bedenkt datt ZFS an Btrfs dëst net maache kënnen: den Design erlaabt et net. Do musst Dir e speziellen Hannergrondscannungsprozess mam Numm "Scrub" lafen a waart bis et an de problematesche Block kënnt. Programméierer nennen sou Eventer figurativ "Krütchen".
A schlussendlech sinn heterogen logesch Bänn erschéngt, alles ubitt, wat ZFS, Btrfs, Blockschicht, souwéi FS + LVM Kombinatiounen am Prinzip net ubidden kënnen - parallel Skaléieren, O (1) Disk Adress Allocator, transparent Datemigratioun tëscht Subvolumen. Déi lescht huet och e User-Interface. Elo kënnt Dir einfach déi wäermst Donnéeën op den héchste Leeschtungsfuerer op Ärem Volume réckelen.
Zousätzlech ass et méiglech dréngend all dreckeg Säiten op sou engem Drive ze spülen, doduerch d'Applikatiounen déi dacks fsync(2) nennen, wesentlech beschleunegen. Ech bemierken datt d'Blockschichtfunktionalitéit, genannt bcache, guer net sou Handlungsfräiheet ubitt. Nei logesch Bänn baséieren op meng Algorithmen (et ginn entspriechend Patenter). D'Software ass scho relativ stabil, et ass ganz méiglech et ze probéieren, d'Leeschtung ze moossen, asw. Déi eenzeg Nodeel ass datt Dir fir de Moment d'Volumenkonfiguratioun manuell aktualiséieren an iergendwou späicheren.
Bis elo konnt ech meng Iddien ëm 10 Prozent ëmsetzen.Ech hunn et awer gelongen, wat ech als déi schwieregst ugesinn hunn - logesch Bänn mat enger Flash-Prozedur ze verbannen, déi all deferred actions am reiser4 ausféiert. Dëst ass nach ëmmer an der experimenteller "format41" Branche.
Passt Reiser4 xfstests?
Op d'mannst huet et fir mech gemaach wann ech déi lescht Verëffentlechung virbereet hunn.
Ass et am Prinzip méiglech Reiser4 engem Netzwierk (Cluster) FS mat Plugins ze maachen?
Et ass méiglech, an och néideg! Wann Dir eng Netzwierkdatei erstellt baséiert op engem richteg entworfene lokalen Dateiesystem, da wäert d'Resultat ganz beandrockend sinn! Am modernen Netzwierk FS sinn ech net zefridden mat der Präsenz vun engem Backend-Späicherniveau, deen mat all lokalen FS ëmgesat gëtt. D'Existenz vun dësem Niveau ass komplett ongerechtfäerdegt. De Reseau FS muss direkt mat der Blockschicht interagéieren, an net de lokalen FS froen fir aner Servicedateien ze kreéieren!
Allgemeng ass d'Divisioun vun Dateiesystemer a lokalen an Netzwierker vum Béisen. Et ass entstanen aus der Onvollstännegkeet vun den Algorithmen, déi virun drësseg Joer benotzt goufen, an amplaz vun deenen nach näischt proposéiert gouf. Dëst ass och de Grond fir d'Erscheinung vun enger Mass vun onnéidege Softwarekomponenten (verschidde Servicer, asw.). Op eng gutt Manéier sollt et nëmmen ee FS a Form vun engem Kernelmodul an eng Rei vu Benotzer Utilities op all Maschinn installéiert sinn - e Cluster Node. Dëse FS ass souwuel lokal wéi Netzwierk. An näischt méi!
Wann näischt mam Reiser4 op Linux klappt, géif ech gären en FS fir FreeBSD ubidden (Zitat aus engem fréieren Interview: "...FreeBSD... huet akademesch Wuerzelen... An dat heescht, datt mir mat enger héijer Wahrscheinlechkeet wäert eng gemeinsam Sprooch mat den Entwéckler fannen") ?
Also, wéi mir just erausfonnt hunn, ass alles scho perfekt mat Linux geklappt: et gëtt e separaten funktionnéierende Reiser4 Hafen dofir a Form vun engem Masterzweig vun eisem Repository. Ech hunn FreeBSD net vergiess! Offer! Ech si prett fir enk mat deenen ze schaffen, déi d'Innere vu FreeBSD gutt kennen. Iwwregens: Wat mir wierklech un hirer Gemeng gefällt ass, datt do Decisioune vun engem aktualiséierten Rot vun onofhängegen Experten geholl ginn, wat näischt mat der Regierungs-Täuschung vun enger permanenter Persoun ze dinn huet.
Wéi bewäert Dir d'Linux Benotzergemeinschaft haut? Ass et méi "Pop" ginn?
Wéinst der Natur vu menger Aarbecht ass et fir mech relativ schwéier dëst ze bewäerten. Meeschtens kommen d'Benotzer bei mech mat Käferberichter an Ufroe fir d'Sektioun ze fixéieren. Benotzer als Benotzer. E puer si méi erfuerderlech, e puer manner. Jiddereen gëtt d'selwecht behandelt. Gutt, wann de Benotzer meng Instruktioune ignoréiert, dann entschëllegt mech: d'Ignoréierungsuerdnung gëtt och vu mengem Säit agefouert.
Ass et méiglech d'Entwécklung vun Dateiesystemer fir déi nächst fënnef bis zéng Joer virauszesoen? Wat mengt Dir sinn d'Haaptfuerderungen déi FS Entwéckler konfrontéieren?
Jo, et ass net schwéier esou eng Prognose ze maachen. Et gouf keng Entwécklung vu Dateisystemer am Upstream fir eng laang Zäit. Nëmmen d'Erscheinung vun esou entsteet. Entwéckler vu lokalen Dateiesystemer hu Problemer mat engem schlechten Design verbonnen. Hei muss ee Caveat gemaach ginn. Ech betruechten net de sougenannte "Späicheren", "Lecken" a Porting vum Code als Entwécklung an Entwécklung. An ech klassifizéieren de Mëssverständnis mam Numm "Btrfs" net als Entwécklung aus de Grënn déi ech scho erkläert hunn.
All Patch mécht nëmme seng Problemer méi schlëmm. Gutt. an et ginn ëmmer verschidden Aarte vu "Evangelisten" fir déi "alles funktionnéiert." Am Fong sinn dëst Schoulkanner a Studenten déi Virträg iwwersprangen. Stellt Iech vir: et funktionnéiert fir hien, awer de Professer net. Wat en Adrenalinschlag ass dëst! Aus menger Siicht ass de gréisste Schued vun den "Handwierker" verursaacht, déi sech begeeschtert hunn déi wonnerbar Feature vu Btrfs op all Zorte vu Schichten wéi Systemd, Docker, etc. - dat gläicht scho mat Metastasen.
Loosst eis elo probéieren eng Prognose fir fënnef bis zéng Joer ze maachen. Ech hu scho kuerz opgezielt, wat mir zu Reiser4 maache wäerten. D'Haaptrei Erausfuerderung fir lokal FS Entwéckler aus upstream wäert ginn (jo, et ass scho ginn) d'Onméiglechkeet eng uerdentlech Aarbecht fir eng Pai ze maachen. Ouni Iddien am Beräich vun der Datelagerung wäerte se weider probéieren dës onglécklech VFS, XFS an ext4 ze patchen. D'Situatioun mam VFS gesäit virun allem komesch aus, an erënnert un déi frenziéiert Moderniséierung vun engem Restaurant, an deem keng Kichecheffe sinn, a kee Kichecheffe erwaart ginn.
Elo sperrt de VFS Code, ouni Konditiounen, verschidde Gedächtnissäiten zur selwechter Zäit an invitéiert den ënnerierdesche FS fir se ze bedreiwen. Dëst gouf agefouert fir d'Ext4 Leeschtung op Läschen Operatiounen ze verbesseren, awer wéi einfach ze verstoen ass, ass sou gläichzäiteg Sperrung komplett inkompatibel mat fortgeschratt Transaktiounsmodeller. Dat ass, Dir kënnt net einfach Ënnerstëtzung fir e Smart Dateiesystem am Kärel addéieren. Ech weess net wat d'Situatioun an anere Beräicher vu Linux ass, awer wat d'Dateisystemer ugeet, ass all Entwécklung hei onwahrscheinlech kompatibel mat der Politik, déi vum Torvalds an der Praxis verfollegt gëtt (akademesch Projete ginn erausgeschloen, a Scammers déi hu keng Ahnung wat e B-Bam , endlos Kreditter vu Vertrauen ausgestallt ginn). Dofir gouf e Kurs fir luesen Zerfall gesat. Natierlech probéieren se mat all hirer Kraaft et als "Entwécklung" ofzeginn.
Weider, de "Depot" vun Fichier Systemer, mierken, datt Dir net vill vun "Späicheren" eleng verdéngen kann, probéieren hir Hand op eng méi rentabel Affär. Dëst sinn, als Regel, verdeelt Dateisystemer a Virtualiséierung. Vläicht portéiere se de fashionable ZFS soss anzwousch wou et nach net gëtt. Awer et, wéi all FS aus dem Upstream, gläicht engem Neijoersbam: wann Dir e puer aner kleng Saachen uewen hänke kënnt, da kënnt Dir net méi déif kréien. Ech zouginn datt et méiglech ass e seriéisen Enterprise System op ZFS ze bauen, awer well mir elo iwwer d'Zukunft diskutéieren, kann ech nëmmen traureg soen datt ZFS hoffnungslos ass an deem Sënn: mat hiren virtuellen Apparater hunn d'Jongen de Sauerstoff ofgeschnidden fir sech selwer an zukünfteg Generatiounen fir weider Entwécklung. ZFS ass eng Saach vun der Vergaangenheet. An ext4 an XFS sinn net emol viru gëschter.
Et ass derwäert getrennt iwwer dat sensationellt Konzept vum "Linux Dateisystem vun der nächster Generatioun" ze ernimmen. Dëst ass e komplett politeschen a Marketingprojet erstallt fir d'Geleeënheet, souzesoen, fir "d'Zukunft vun Dateiesystemer" op Linux hannert spezifesche Charakteren ze pinnen. De Fakt ass datt Linux fréier "just for fun" war. Awer elo ass et virun allem eng Geldmaschinn. Si sinn op alles méiglech gemaach. Zum Beispill ass et ganz schwéier e gudde Softwareprodukt ze kreéieren, awer intelligent "Entwéckler" hu laang gemierkt datt et guer net néideg ass ze belaaschten: Dir kënnt erfollegräich net existent Software verkafen, déi an allen ëffentlechen Ukënnegungen ugekënnegt a gefördert gouf. Eventer - den Haapt Saach ass datt d'Presentatioun Rutschen méi "Features" sollten enthalen.
Dateisystemer si perfekt fir dëst, well Dir kënnt sécher zéng Joer iwwer d'Resultat verhandelen. Gutt, wann een spéider iwwer de Mangel vun dësem Resultat beschwéiert, da versteet hien einfach näischt iwwer Dateiesystemer! Dëst erënnert un eng Finanzpyramid: un der Spëtzt sinn d'Abenteuer, déi dëse Chaos ugefaangen hunn, an déi puer, déi "Gléck" haten: si hunn "Dividenden zréckgezunn", d.h. Sue fir Entwécklung kritt, eng gutt bezuelten Aarbecht als Manager kritt, op Konferenzen "opgewise" asw.
Als nächst kommen déi, déi "Onglécklech" sinn: Si zielen Verloschter, këmmeren sech mat de Konsequenze vun der Ofsetzung vun engem onbenotzbare Softwareprodukt an d'Produktioun, "asw. Et gi vill méi vun hinnen. Gutt, op der Basis vun der Pyramid gëtt et eng rieseg Mass vun Entwéckler, déi onnëtze Code "säien". Si sinn déi gréisste Verléierer, well verschwenden Zäit kann net zréck ginn. Esou Pyramiden sinn extrem gutt fir Torvalds a seng Mataarbechter. A wat méi vun dëse Pyramiden, wat besser fir si. Fir sou Pyramiden ze ernähren, kann alles an de Kär geholl ginn. Natierlech soen se an der Ëffentlechkeet de Géigendeel. Awer ech beurteelen net duerch Wierder, mee duerch Handlungen.
Also, "d'Zukunft vun Dateiesystemer am Linux" ass nach eng aner héich gefördert, awer kaum benotzbar Software. No Btrfs, mat enger héijer Wahrscheinlechkeet, gëtt d'Plaz vun esou enger "Zukunft" vu Bcachefs geholl, wat e weidere Versuch ass fir d'Linux Blockschicht mat engem Dateiesystem ze iwwerschreiden (e schlecht Beispill ass ustiechend). A wat typesch ass: et ginn déi selwecht Problemer wéi am Btrfs. Ech hunn dëst laang verdächtegt, an dunn iergendwéi konnt ech net widderstoen an de Code kucken - et ass wouer!
D'Auteuren vu Bcachefs a Btrfs, wann se hir FS kreéieren, hunn d'Quell vun anere Leit aktiv benotzt, wéineg iwwer si verstanen. D'Situatioun erënnert ganz un d'Kannerspill "gebrochenen Telefon". An ech ka mir ongeféier virstellen wéi dëse Code am Kärel abegraff ass. Eigentlech wäert keen d'"Rakes" gesinn (jidderee wäert méi spéit op se trëppelen). No villen Aussoen iwwer de Stil vum Code, Ukloe vu net existente Verstouss, asw., gëtt eng Conclusioun iwwer d'"Loyalitéit" vum Auteur gemaach, wéi gutt hien mat aneren Entwéckler "interagéiert" a wéi erfollegräich all dëst kann dann u Firmen verkaaft ginn.
D'Ennresultat wäert keen interesséieren. Virun 20 Joer wier ech vläicht interesséiert, mä elo ginn d'Froen anescht gestallt: Ass et méiglech, dat ze förderen, datt verschidde Leit an den nächsten zéng Joer agestallt ginn. An, leider, et ass net üblech sech iwwer d'Ennresultat ze wonneren.
Am Allgemengen, géif ech staark roden géint ufänken Äre Fichier System vun Null nei ze erfannen. Well och bedeitend finanziell Investitioune ginn net duer fir an zéng Joer eppes kompetitiv ze kréien. Natierlech schwätzen ech iwwer sérieux Projeten, an net iwwer déi, déi virgesi sinn, an de Kärel "gedréckt" ze ginn. Also, e méi effektive Wee fir Iech selwer auszedrécken ass richteg Entwécklungen matzemaachen, wéi eis. Dëst ass natierlech net einfach ze maachen - awer dëst ass de Fall mat all héije Projet.
Als éischt musst Dir onofhängeg de Problem iwwerwannen, deen ech ubidden. Duerno, iwwerzeegt vun der Eescht vun Ären Intentiounen, wäert ech ufänken ze hëllefen. Traditionell benotze mir nëmmen eis eegen Entwécklungen. D'Ausnahmen si Kompressiounsalgorithmen an e puer Hashfunktiounen. Mir schécken Entwéckler net fir op Konferenzen ze reesen, an da sëtze mir net a kombinéiere aner Leit hir Iddien ("vläicht wat wäert geschéien"), wéi et an de meeschte Startups üblech ass.
Mir entwéckelen all Algorithmen selwer. Ech sinn de Moment interesséiert an den algebraeschen a kombinatoreschen Aspekter vun der Datespeicherwëssenschaft. Besonnesch endlech Felder, Asymptotik, Beweis vun Ongläichheeten. Et gëtt och Aarbecht fir gewéinlech Programméierer, awer ech muss Iech direkt warnen: all Suggestioune fir "en aneren FS ze kucken an datselwecht ze maachen" ginn ignoréiert. Patches, déi op méi enk Integratioun mat Linux iwwer VFS zielen, ginn och dohinner.
Also, mir hu keng Rake, awer mir hunn e Verständnis vu wou mir musse plënneren, a mir hunn Vertrauen datt dës Richtung déi richteg ass. Dëst Verständnis ass net a Form vu Manna vum Himmel komm. Loosst mech Iech drun erënneren datt mir 29 Joer Entwécklungserfarung hannert eis hunn, zwee Dateiesystemer vun Null geschriwwe ginn. An déi selwecht Zuel vun Daten Erhuelung Utilities. An dëst ass vill!
Source: opennet.ru