Eduard Shishkin Reiser4 fitxategi sistemaren garatzaileari egindako bigarren elkarrizketa argitaratu da.
Hasteko, gogoratu irakurleei non eta norentzat lan egiten duzun.
Biltegiratze-arkitektu nagusi gisa lan egiten dut Huawei Technologies-en, Alemaniako Ikerketa Zentroan. Birtualizazio sailean datuak biltegiratzeko hainbat alderdi jorratzen ditut. Nire jarduerak ez daude sistema eragile zehatz batekin lotuta.
Nukleoaren adar nagusiarekin konprometitzen al zara?
Oso gutxitan, eta nire enpresariak hala eskatzen badu. Azken aldia duela hiru urte inguru izan zen, adabakiak bidali nituen ostalarietan partekatutako biltegiratze-maila handitzeko 9p protokoloa erabiliz (enpresa honen beste izen bat VirtFS da). Ohar garrantzitsu bat egin behar da hemen: Linux-ekin aspalditik lanean nabilen arren, ez naiz inoiz zale izan, hau da, “arnasa berdintsu hartzen dut”, beste guztiarekin bezala. Batez ere, akatsen bat nabaritzen badut, gehienez ere seinalatu dezaket. Eta, ondoren, norbait jarraitu eta konbentzitzeko, ez da hori gertatuko.
Gogoan dut azken aldian, duela hamar urte, nahiko kritiko zinela nukleoaren garapen estiloarekin. Zure (edo agian korporatiboa) ikuspuntutik, zerbait aldatu al da, komunitatea sentikorragoa bihurtu da ala ez? Hala ez bada, nor dela uste duzu errua?
Ez nuen inoiz hoberako aldaketarik ikusi. Komunitatearen arazo nagusia zientzia teknologia politikoekin ordezkatzea da, harreman pertsonalak, gehiengoaren iritzia, populismoa, "barneko ahotsen" aholkuak, konpromiso ustelak, zientzia ez den beste edozer. Informatika, edozer esan daitekeena, zientzia zehatza da lehenik eta behin. Eta norbait 2x2-ren balio propioa aldarrikatzen hasten bada, 4-tik desberdina, "Linux modua" banderaren azpian edo beste banderaren baten azpian, orduan ez da kalterik ekarriko.
Arazo guztiak erabakiak hartzen dituztenen gaitasun ezaren eta heziketa ezaren ondorio dira batez ere. Kudeatzailea ezgaia bada, ez da gai erabaki objektibo eta egoki bat hartzeko. Kulturarik gabekoa bada ere, ezin du aholku egokia emango dion espezialista eskudun bat aurkitzeko. Probabilitate handiarekin, "itxuraz zuzenak diren gauzak" esaten dituen iruzurgile batengan geratuko da aukera. Ingurune ustela beti garatzen da lider bakarti ezgaien inguruan. Gainera, historiak ez du salbuespenik ezagutzen alde horretatik, eta komunitatea da horren baieztapen argiena.
Nola baloratzen duzu Btrfs garapenean izandako aurrerapena? FS honek haurtzaroko gaixotasunak kendu al zituen? Nola kokatzen duzu zeuretzat - FS gisa "etxerako" edo erabilera korporatiborako ere?
Ez nuen kendu. Duela 11 urte aipatu nuen guztia gaurkoa da oraindik. Behar larrietarako desegokitzen den Btrfs-en arazoetako bat espazio librearen arazoa da. Ez naiz hitz egiten erabiltzaileari dendara disko berri baten bila exekutatzeko eskatzen zaion beste edozein FSk partizioan leku libre asko erakutsiko lukeen egoeretan. Espazio librearen faltagatik bolumen logiko batean eragiketa bat burutzeko ezintasuna ere ez da okerrena. Okerrena da pribilegiorik gabeko erabiltzaile batek ia beti, edozein disko-kuotak saihestu, denei espazio librea nahiko denbora laburrean ken diezaiekeela.
Honela dirudi (Linux kernel 5.12rako probatua). Script bat abiarazten da instalatu berri den sistema batean, eta horrek begizta batean izen jakin batzuk dituzten fitxategiak sortzen ditu hasierako direktorioan, datuak desplazamendu jakin batzuetan idazten ditu eta, ondoren, fitxategi horiek ezabatzen ditu. Script hau exekutatzen minutu bat igaro ondoren, ez da ezer arrarorik gertatzen. Bost minutu igaro ondoren, partizioan okupatutako espazioaren zatia pixka bat handitzen da. Bi edo hiru orduren buruan %50era iristen da (hasierako balioarekin %15ekoa). Eta bost edo sei orduko lanaren ondoren, scripta huts egiten du "partizioan ez dago leku librerik". Horren ondoren, jada ezin duzu 4K fitxategirik idatzi ere zure partizioan idatzi.
Egoera interesgarri bat gertatzen da: azkenean ez zenuen partizioan ezer idazten, eta leku libre guztia (%85 inguru) desagertu zen nonbait. Eraso hori jasan duen atal baten analisiak elementu bakarra (giltzaz hornitutako objektu bat) duten zuhaitz-nodo asko agerian utziko ditu, hainbat byte-tamaina. Hau da, lehen diskoko espazioaren % 15 okupatzen zuen edukia partizio osoan zehar berdin "ziztatuta" zegoen, fitxategi berri bat idazteko inon ez izateko, bere gakoa lehendik dauden guztiak baino handiagoa delako eta doakoa. partizioaren blokeak agortu dira.
Gainera, hori guztia Btrfs oinarrizko konfigurazioan gertatzen da jada (inolako argazkirik, azpibolumenik, etab. gabe), eta berdin dio nola erabakitzen duzun fitxategi-gorputzak FS horretan gordetzea (zuhaitz batean "zatiak" gisa edo hedadura gisa). formateatu gabeko blokeen) - azken emaitza berdina izango da.
Ezin izango dituzu gorako beste fitxategi-sistemak halako eraso baten menpe jarri (esaten dizutena ere). Aspaldi azaldu nuen arazoaren zergatia: Btrfs-en B-zuhaitz kontzeptuaren erabateko perbertsioa da hau, berez edo nahita degeneratzea posible egiten duena. Bereziki, karga jakin batzuetan, zure fitxategi-sistema etengabe "desegingo" da funtzionatzen den bitartean, kanpoko laguntzarik gabe. Argi dago atzeko planoko prozesu mota guztiek mahaigain indibidualetan soilik gordeko dutela.
Zerbitzari kolektiboetan, erasotzaile batek beti izango du "aurrera" egiteko gai. Sistemaren administratzaileak ezingo du zehatz-mehatz jazarpena egin duen zehaztu ere egin. Btrfs-en arazo hau konpontzeko modurik azkarrena B-zuhaitz arrunt baten egitura berreskuratzea da, hau da. diskoaren formatua birdiseinatzea eta Btrfs kodearen zati esanguratsuak berridaztea. Honek 8-10 urte beharko ditu, arazketa barne, baldin eta garatzaileek zorrozki jarraitu badituzte algoritmo eta datu-egiturei buruzko jatorrizko artikuluak, eta ez badute "hautsitako telefonoa" jokoan jokatu, "Linux"-en ohikoa (eta animatzen den moduan). bidea”.
Hemen ere garatzaileek hau guztia ulertzeko behar duten denbora gehitu behar dugu. Hemen zailagoa da. Nolanahi ere, 10 urte ez ziren nahikoa izan ulertzeko. Tira, ordura arte ezin duzu miraririk espero. Ez da gertatuko "zuk eta biok ezagutzen ez genuen" muntatzeko aukera baten moduan edo prestatzeko "negozio kontua besterik ez den" adabaki baten moduan. Halako "konponketa" presatsu bakoitzeko, endekapenezko eszenatoki berri bat aurkeztuko dut. B-zuhaitzak dira nire gai gogokoenetako bat, eta esan behar dut egitura hauek ez dutela askatasunik onartzen euren buruarekin!
Nola kokatzen ditut Btrfs niretzat? Fitxategi-sistema dei ezin daitekeen zerbait bezala, are gutxiago erabili. Zeren eta, definizioz, FS "disko-espazioa" baliabidearen kudeaketa eraginkorraz arduratzen den OS azpisistema bat da, Btrfs-en kasuan ikusten ez duguna. Bada, imajinatu dendara erloju bat erostera etortzen zarela lanera berandu ez joateko, eta erloju baten ordez tenporizadoredun parrilla elektrikoa saltzen dizutela gehienez 30 minutuz. Beraz, Btrfs-en egoera are okerragoa da.
Posta-zerrendetan begiratuta, askotan diskoaren espazioa modu eraginkorrean kudeatzea ez dela garrantzitsua diskoen merketasuna dela eta. Hau erabateko zentzugabekeria da. Disko espazioaren kudeatzaile eraginkorrik gabe, sistema eragilea zaurgarria eta erabilezin bihurtuko da. Zure makinako diskoen edukiera edozein dela ere.
RHEL-en Btrfs laguntza etenari buruzko iruzkin bat eskatu nahiko nuke.
Hemen ez dago komentatzeko ezer berezirik, dena oso argi dago. “Aurreikuspen teknologiko” gisa ere izan zuten. Beraz, ez nuen oso "aurrebista" honetatik pasatu. Ez utzi etiketa hau betiko zintzilik! Baina ezin dute abiarazi diseinuaren araberako produktu akastun bat laguntza osoarekin. RHEL enpresa bat da, hau da, merkantzia-diru harreman aginduak. Red Hat-ek ezin ditu erabiltzaileak jazarri Btrfs posta-zerrendan egiten duten bezala. Imajinatu egoera: gogor irabazitako dirua diskoagatik eta zuk laguntzagatik ere ordaindu zuen bezero batek, ezer idatzi ez zuenean bere diskoko espazioa non zegoen ulertu nahi du. Zer erantzungo diozu honi?
Aurrerago. Red Hat-en bezeroen artean banku eta truke handiak ezagunak daude. Imajinatu zer gertatuko litzatekeen Btrfs-en aipatutako ahultasunean oinarritutako DoS erasoen menpe egongo balira. Nor dela uste duzu honen erantzule? GPL lizentziaren lerroa hatza seinalatzear daudenei, non egileak ez duela ezeren erantzule idatzita, berehala esango diet: “ezkutatu!”. Red Hat-ek erantzungo du, eta nahikoa ez dirudien moduan! Baina badakit Red Hat-ek ez duela mota honetako arazoei aurre egiten, bere QA ingeniarien talde bereziki sendoa ikusita, eta horrekin estuan lan egiteko aukera izan nuen nire garaian.
Zergatik jarraitzen dute enpresa batzuek Btrfs onartzen beren enpresa-produktuetan?
Kontuan izan produktuaren izenean dagoen "enpresa" aurrizkiak ez duela askorik esan nahi. Enpresa bezeroarekiko kontratu-harremanean txertatutako erantzukizunaren neurria da. GNU/Linux-en oinarritutako enpresa bakarra ezagutzen dut - RHEL. Gainerako guztia, nire ikuspuntutik, enpresa gisa baino ez da aurkezten, baina ez da bat. Eta, azkenik, zerbaiten eskaria badago, beti egongo da eskaintza (gure kasuan, aipatutako "euskarria" da). Guztietarako eskaera dago, barne. eta erabilezin den softwarea. Eskaera hori nola sortzen den eta nork elikatzen duen beste gai bat da.
Beraz, ez nuke inolako ondoriorik aterako Facebook-ek bere zerbitzarietan Btrfs zabaldu zuela esan ondoren. Gainera, zerbitzari horien helbideak sekretuan gordetzea gomendatuko nuke, aipatutako arrazoiengatik.
Zergatik egin da hainbeste ahalegin XFS kodea garbitzeko azkenaldian? Azken finean, hasiera batean hirugarrenen fitxategi-sistema bat da, eta ext4 egonkorra izan da denbora luzez eta aurreko bertsio berdin egonkorren jarraipena du. Zer interes dauka Red Hatek XFS-n? Zentzurik al du helburuz antzekoak diren bi fitxategi-sistema aktiboki garatzeak - ext4 eta XFS?
Ez dut gogoratzen zerk bultzatu zuen hau. Litekeena da ekimena Red Hat-en bezeroetatik etorri izana. Gogoan dut mota honetako ikerketak egin zirela: gorako fitxategi-sistema batzuetan, belaunaldi berriko goi mailako diskoetan objektu kopuru erraldoi bat sortu zen. Emaitzen arabera, XFS ext4 baino hobeto portatu zen. Beraz, itxaropentsuena zela sustatzen hasi ziren. Nolanahi ere, hemen ez nuke ezer sentsaziorik bilatuko.
Niretzat, awl bat xaboiarekin ordezkatu duten bezala da. Ez du balio ext4 eta XFS garatzea. Biak paraleloan eta horietako edozein aukeran. Honetatik ez da ezer onik aterako. Nahiz eta naturan hazteko ahalmen handia dagoen egoerak egon ohi dira, baina ez dago hazteko lekurik. Kasu honetan, hainbat hazkunde berri bitxi eta itsusi sortzen dira, eta denek hatza seinalatzen dute ("Ai, begira, zer ez duzu ikusiko bizitza honetan!").
Uste duzu geruzaren urraketaren arazoa konpondu dela (zentzu negatiboan) ext4, F2FS-en enkriptazio-funtzioen agerpenarekin (RAID Btrfs-en aipatzearren)?
Oro har, edozein maila ezartzea eta hauen ez-urraketari buruzko erabakia hartzea politika kontua izan ohi da, eta ez dut hemen ezer komentatzeko konpromisoa hartzen. Geruzen urraketaren alderdi objektiboak inori interes gutxikoak dira, baina horietako batzuk kontuan izan ditzakegu "goitik" urratzearen adibidea erabiliz, hots, bloke geruzan dagoeneko existitzen den funtzionalitate FSn inplementatzea. Halako "urraketa" salbuespen bakanekin justifikatzen da. Halako kasu bakoitzerako, lehenik eta behin bi gauza frogatu behar dituzu: benetan beharrezkoa dela eta sistemaren diseinuari ez zaiola kalterik egingo.
Adibidez, ispiluak, tradizionalki bloke geruzaren jarduera izan dena, zentzuzkoa da fitxategi-sistema mailan ezartzea. Arrazoi ezberdinengatik. Adibidez, datuen ustelkeria "isila" (bit usteldura) disko unitateetan gertatzen da. Hau da gailua behar bezala funtzionatzen duenean, baina blokearen datuak ustekabean kaltetzen dira urrutiko quasar batek igorritako gamma-quantum gogor baten eraginez, etab. Okerrena da bloke hau FS sistemaren blokea bihurtzen bada (superblokea, bitmap blokea, biltegiratze zuhaitz-nodoa, etab.), horrek kernel izua ekarriko duelako zalantzarik gabe.
Kontuan izan bloke-geruzak eskaintzen dituen ispiluek (RAID 1 deritzona) ez zaituela arazo honetatik salbatuko. Beno, benetan: norbaitek checksumak egiaztatu eta erreplika irakurri beharko luke hutsegite kasuan? Horrez gain, zentzuzkoa da dena ez ezik, metadatuak soilik ispilatzea. Datu garrantzitsu batzuk (adibidez, aplikazio kritikoen fitxategi exekutagarriak) metadatu gisa gorde daitezke. Kasu honetan, segurtasun berme berberak jasotzen dituzte. Zentzuzkoa da gainerako datuen babesa beste azpisistemei (agian erabiltzaileen aplikazioei ere) uztea - horretarako beharrezko baldintza guztiak eman ditugu.
Ispilu "ekonomiko" horiek existitzeko eskubidea dute, eta fitxategi-sistemaren mailan soilik modu eraginkorrean antolatu daitezke. Bestela, geruzak urratzea kode bikoiztua duen azpisistema bat nahasten da onura mikroskopiko batzuen mesedetan. Horren adibide deigarri bat FS erabiliz RAID-5 inplementatzea da. Horrelako irtenbideek (RAID / LVM propioa fitxategi-sisteman) azken hau hiltzen dute arkitektura terminoetan. Kontuan izan behar da, gainera, geruzaren urraketa hainbat marketin-iruzurgileek "korrontean" jartzen dutela. Ideiarik ezean, aldameneko mailetan aspaldi inplementatu den funtzionaltasuna gehitzen zaie azpisistemei, oso erabilgarria den ezaugarri berri gisa aurkezten da eta aktiboki bultzatzen da.
Reiser4 mailak «behetik» urratzea leporatu zioten. Fitxategi-sistema ez dela monolitikoa, beste guztiak bezala, modularra baizik, oinarririk gabeko hipotesi bat egin zen goiko mailak (VFS) egin beharko lukeena egiten duela.
Posible al da ReiserFS v3.6 eta, adibidez, JFS-ren heriotzaz hitz egin? Azkenaldian ez dute ia arretarik jaso muinean. Zaharkituta daude?
Hemen software produktu baten heriotzak zer esan nahi duen definitu behar dugu. Alde batetik, arrakastaz erabiltzen dira (horretarako sortu ziren, azken finean), hau da, bizi dira. Bestalde, ezin dut JFSaz hitz egin (ez dakit asko), baina ReiserFS (v3) oso zaila da joera berrietara egokitzea (praktikan probatua). Horrek esan nahi du etorkizunean garatzaileek ez diotela arreta jarriko, moldatzen errazagoak direnei baizik. Alde horretatik ateratzen da, ai, arkitektura aldetik hilda dagoela. "Moralki zaharkitua" kontzeptua ez nuke batere manipulatuko. Ondo aplikatzen da, adibidez, armairu bati, baina ez software produktuei. Gutxiagotasun eta nagusitasun kontzeptu bat dago zerbaitetan. Erabat esan dezaket ReserFS v3 Reiser4 baino txikiagoa dela denetan, baina lan-karga mota batzuetan gorako beste FS guztien gainetik dagoela.
Ba al dakizu FS Tux3 eta HAMMER/HAMMER2 (FS DragonFly BSD) garapenaren berri?
Bai, badakigu. Tux3-n noizbait haien argazkien teknologia interesatzen zitzaidan («bertsio-erakusleak» deiturikoak), baina Reiser4-n ziurrenik beste bide batetik joango gara. Aspalditik nabil argazkien laguntzari buruz pentsatzen eta oraindik ez dut erabaki nola inplementatu Reiser4 bolumen soiletarako. Kontua da Ohad Rodeh-k proposatutako "alferra" erreferentziazko kontagailu teknika berriak B zuhaitzetarako soilik funtzionatzen duela. Ez ditugu. Reiesr4-n erabiltzen diren datu-egitura horietarako, kontagailu "alferrak" ez dira definitzen; horiek aurkezteko, beharrezkoa da zenbait problema algoritmiko ebaztea, oraindik inork hartu ez dituenak.
HAMMERren arabera: Sortzailearen artikulu bat irakurri dut. Ez da interesatzen. Berriz ere, B-zuhaitzak. Datu-egitura hau guztiz zaharkituta dago. Joan den mendean bertan behera utzi genuen.
Nola baloratzen duzu CephFS/GlusterFS/etab bezalako sare-klusterren FS-en eskaera gero eta handiagoa? Eskaera honek garatzaileen lehentasunen aldaketa sareko FSrantz eta tokiko FSri behar besteko arretarik ez izatea esan nahi al du?
Bai, lehentasunen aldaketa hori gertatu da. Fitxategi-sistemen tokiko garapena gelditu egin da. Ala ere, tokiko bolumenetarako esanguratsua den zerbait egitea nahiko zaila da orain eta denek ezin dute egin. Inork ez du bere garapenean inbertitu nahi. Merkataritza-erakunde bati ikerketa matematikorako dirua bideratzeko eskatzearen berdina da hori; inolako gogorik gabe teorema berri batekin dirua nola irabazi dezakezun galdetuko dizute. Orain, tokiko FS bat magiaz "kutxatik kanpo" agertzen den zerbait da eta "beti funtzionatu beharko luke", eta ez badu funtzionatzen, erantzun gabeko marmak eragiten ditu: "Bai, zer pentsatzen ari dira!"
Hortik tokiko FSri arreta falta, nahiz eta oraindik lan asko dagoen arlo horretan. Bai, denek biltegiratze banatura jo dute, lehendik dauden fitxategi-sistem lokaletan oinarrituta eraikita dagoena. Oso modan dago orain. “Big Data” esaldiak adrenalina igoera eragiten du askorentzat, hitzaldiekin, lantegiekin, soldata handiekin, etab.
Zein zentzuzkoa da printzipioz sareko fitxategi-sistema kernel-espazioan ezartzea erabiltzaile-espazioan baino?
Oso zentzuzkoa den ikuspegia, oraindik inon ezarri ez dena. Orokorrean, sareko fitxategi-sistema zein espaziotan ezarri behar den galdera "aho biko ezpata" da. Tira, ikus dezagun adibide bat. Bezeroak datuak urruneko makina batean grabatu zituen. Orrialde zikin moduan erori ziren bere orrialdeen cachean. Hau da kernel-espazioko sareko fitxategi-sistemaren "atebide mehe" baten lana. Orduan sistema eragileak lehenago edo beranduago orrialde horiek diskoan idazteko eskatuko dizu haiek askatzeko. Ondoren, IO-birbidaltzeko (bidaltzeko) sareko FS modulua sartzen da jokoan. Orrialde hauek zein zerbitzari-makina (zerbitzari-nodo) joango diren zehazten du.
Ondoren, sareko pila hartzen du (eta, dakigunez, kernel espazioan inplementatzen da). Ondoren, zerbitzari-nodoak pakete hori jasotzen du datuekin edo metadatuekin, eta backend biltegiratze-moduluari (hau da, kernel-espazioan funtzionatzen duen tokiko FS-ari) gauza horiek guztiak grabatzeko agintzen dio. Beraz, galdera "bidaltzeko" eta "jasotzeko" moduluek non funtzionatu behar duten murriztu dugu. Modulu horietakoren bat erabiltzailearen espazioan exekutatzen bada, horrek ezinbestean testuinguru aldaketa ekarriko du (kernel zerbitzuak erabili beharra dagoelako). Etengailu horien kopurua ezarpenaren xehetasunen araberakoa da.
Horrelako etengailu asko badaude, biltegiratze-erritmoa (I/O errendimendua) gutxituko da. Zure backend biltegiratzea disko motelez osatuta badago, orduan ez duzu jaitsiera nabarmenik nabarituko. Baina disko azkarrak badituzu (SSD, NVRAM, etab.), orduan testuinguru-aldaketa jada "botila" bihurtzen da eta, testuinguru-aldaketa aurreztuz, errendimendua nabarmen handitu daiteke. Dirua aurrezteko modu estandarra moduluak kernel espaziora eramatea da. Esate baterako, aurkitu dugu 9p zerbitzaria QEMUtik kernelera ostalariaren makina mugitzeak VirtFS errendimendua hirukoiztu egiten duela.
Hau, noski, ez da sareko FS bat, baina gauzen esentzia guztiz islatzen du. Optimizazio honen alde txarra eramangarritasun arazoak dira. Batzuentzat, azken hau kritikoa izan daiteke. Adibidez, GlusterFS-k ez du inongo modulurik nukleoan. Horri esker, gaur egun plataforma askotan funtzionatzen du, NetBSD barne.
Zein kontzeptu har ditzakete tokiko FSek sarekoetatik eta alderantziz?
Gaur egun, sareko FS-ek, oro har, gehigarriak dituzte tokiko FS-en gainean, beraz, ez dut ondo ulertzen azken honetatik zerbait mailegatu dezakezun. Bada, egia esan, har dezagun 4 langileko enpresa bat, zeinetan bakoitzak berea egiten duen: batek banatzen du, beste batek bidaltzen du, hirugarrenak jasotzen du, laugarrenak dendak. Eta galdera, zer maileguan har diezaiokeen enpresak hura gordetzen duen langileari, nolabait okerra dirudi (aspalditik badu jadanik maileguan har zezakeena).
Baina tokiko FSek asko dute ikasteko sarekoetatik. Lehenik eta behin, haiengandik ikasi beharko zenuke bolumen logikoak maila altuan nola agregatu. Orain deiturikoa Fitxategi-sistema lokal "aurreratuek" bolumen logikoak gehitzen dituzte LVM-tik maileguan hartutako "gailu birtuala" teknologia (ZFSn lehen inplementatu zen geruza infekziosoen urraketa bera) soilik erabiliz. Beste era batera esanda, helbide birtualak (bloke-zenbakiak) benetakoetara itzultzea eta atzera maila baxuan gertatzen da (hau da, fitxategi-sistemak I/O eskaera bat igorri ondoren).
Kontuan izan bloke geruzan kokatutako bolumen logikoetan (ez ispiluetan) gailuak gehitzeak eta kentzeak "eginbide" horien hornitzaileek apur bat isilik dituzten arazoak sortzen dituela. Gailu errealetan zatikatzeaz ari naiz, balio ikaragarrietara irits daitezkeenak, gailu birtualean dena ondo dagoen bitartean. Hala ere, jende gutxi dago gailu birtualetan interesa: denek interesa dute zure gailu errealetan gertatzen ari denaz. Baina ZFS antzeko FS (baita LVMrekin batera edozein FS) disko birtualeko gailuekin bakarrik funtzionatzen dute (esleitu disko birtualaren helbideak doakoen artean, desfragmentatu gailu birtual horiek, etab.). Eta ez dakite zer gertatzen den benetako gailuetan!
Orain imajinatu gailu birtualean zero zatiketa duzula (hau da, hedadura erraldoi bat besterik ez duzu bizi bertan), disko bat gehitzen diozula zure bolumen logikoari, eta gero beste ausazko disko bat kendu zure bolumen logikotik eta, gero, orekatu. Eta hainbeste aldiz. Ez da zaila imajinatzea gailu birtualean hedadura bera izango duzula bizirik, baina benetako gailuetan ez duzu ezer onik ikusiko.
Okerrena da egoera hau zuzentzeko gai ere ez zarela! Hemen egin dezakezun gauza bakarra fitxategi-sistemari gailu birtuala desfragmentatzeko eskatzea da. Baina han dena bikaina dela esango dizu - neurri bakarra dago, zatiketa zero da eta ezin da hobea izan! Beraz, bloke mailan antolatutako bolumen logikoak ez dira gailuak behin eta berriz gehitzeko/kentzeko pentsatuta. Modu onean, behin bakarrik muntatu behar duzu bolumen logiko bat bloke mailan, fitxategi-sistemari eman eta, gero, beste ezer egin.
Horrez gain, FS+LVM azpisistema independenteen konbinazioak ez digu uzten bolumen logikoak agregatzen diren unitateen izaera desberdinak kontuan hartzea. Izan ere, demagun HDD eta egoera solidoko gailuetatik bolumen logiko bat muntatu duzula. Baina lehenak desfragmentazioa eskatuko du, eta bigarrenak ez. Azken hauetarako, baztertzeko eskaerak egin behar dituzu, baina lehenengoetarako, ez, etab. Hala ere, konbinazio honetan nahiko zaila da selektibitate hori frogatzea.
Kontuan izan fitxategi-sisteman zure LVM propioa sortu ondoren, egoera ez dela askoz hobetzen. Gainera, hori eginez gero etorkizunean inoiz hobetzeko aukerari amaiera ematen diozu. Hau oso txarra da. Unitate mota desberdinak makina berean bizi daitezke. Eta fitxategi-sistemak ez baditu haien artean bereizten, orduan nork egingo du?
Beste arazo bat deitzen denaren zain dago. "Write-Anywhere" fitxategi-sistemak (honek Reiser4 ere barne hartzen du, muntatzerakoan transakzio-eredu egokia zehaztu baduzu). Horrelako fitxategi-sistemek beren ahalmenean aurrekaririk gabeko desfragmentazio-tresnak eman behar dituzte. Eta maila baxuko bolumen-kudeatzaileak ez du laguntzen hemen, baina oztopatzen du. Izan ere, kudeatzaile horrekin zure FS-ak gailu bakarreko bloke libreen mapa gordeko du - birtual bat. Horren arabera, gailu birtual bat bakarrik desfragmentatu dezakezu. Horrek esan nahi du zure desfragmentatzaileak denbora luzez eta luzez funtzionatuko duela helbide birtualen espazio bakar handi batean.
Eta erabiltzaile asko ausazko gainidazketa egiten badituzu, desfragmentatzaile horren efektu erabilgarria zerora murriztuko da. Zure sistema ezinbestean moteltzen hasiko da, eta eskuak tolestu besterik ez dituzu egin beharko "diseinu hautsi" diagnostiko etsigarriaren aurrean. Helbide-espazio berean exekutatzen diren hainbat desfragmentatzailek elkarren artean soilik oztopatzen dute. Guztiz bestelakoa da benetako gailu bakoitzerako doako blokeen mapa mantentzen baduzu. Honek desfragmentazio-prozesua modu eraginkorrean paralelizatuko du.
Baina hau maila altuko bolumen kudeatzaile logiko bat baduzu bakarrik egin daiteke. Horrelako kudeatzaileekin tokiko fitxategi-sistemak ez ziren lehenago existitzen (ez dakit behintzat). Sareko fitxategi-sistemek (adibidez GlusterFS) soilik zituzten kudeatzaileak. Beste adibide garrantzitsu bat bolumenaren osotasuna egiaztatzeko (fsck) utilitatea da. Azpibolumen bakoitzeko bloke libreen mapa independentea gordetzen baduzu, bolumen logiko bat egiaztatzeko prozedura modu eraginkorrean paralelizatu daiteke. Beste era batera esanda, goi-mailako kudeatzaileak dituzten bolumen logikoak hobeto eskalatzen dira.
Horrez gain, maila baxuko bolumen-kudeatzaileekin ezin izango duzu argazki osorik antolatu. LVM eta ZFS antzeko fitxategi-sistemekin, argazki lokalak bakarrik egin ditzakezu, baina ez argazki globalak. Tokiko argazkiek fitxategi-eragiketa arruntak soilik atzera egiteko aukera ematen dute. Eta han inork ez ditu atzera botako bolumen logikoekin (gailuak gehitzea/kentzea). Ikus dezagun adibide batekin. Uneren batean, 100 fitxategi dituzten A eta B gailuen bolumen logikoa duzunean, S sistemaren argazki bat hartzen duzu eta gero beste ehun fitxategi sortzen dituzu.
Horren ostean, C gailua gehitzen diozu zure bolumenari, eta, azkenik, zure sistema itzularazi Snapshot-era. Galdera: Zenbat fitxategi eta gailu ditu zure bolumen logikoak S-ra itzuli ondoren? 100 fitxategi egongo dira, asmatu zenuten bezala, baina 3 gailu egongo dira - A, B eta C gailu berdinak dira, nahiz eta argazkia sortu zen unean bi gailu baino ez zeuden sisteman (A eta B ). Gehitu C gailua eragiketa ez zen atzera egin, eta orain C gailua ordenagailutik kentzen baduzu, zure datuak hondatuko ditu, beraz, ezabatu aurretik, lehen operazio garesti bat egin beharko duzu gailua berrerekatzeko bolumen logikotik kentzeko, hau da. C gailutik A eta B gailuetara sakabanatu egingo ditu datu guztiak. Baina zure FS-ak argazki globalak onartzen baditu, ez litzateke oreka hori beharrezkoa izango, eta S-ra berehala itzuli ondoren, C gailua ordenagailutik segurtasunez kendu dezakezu.
Beraz, argazki globalak onak dira, datu kopuru handiarekin gailu bat bolumen logiko batetik (bolumen logiko batera) garestia kentzea (gehitzea) saihesteko aukera ematen baitute (noski, zure sistema "snapshot" egitea gogoratzen baduzu). une egokian). Gogorarazten dizut argazkiak sortzea eta fitxategi-sistema horietara itzultzea berehalako eragiketak direla. Galdera sor daiteke: nola da posible hiru egun behar izan dituzun bolumen logiko batean eragiketa bat berehala atzera egitea? Baina posible da! Baldin eta zure fitxategi-sistema behar bezala diseinatuta badago. Duela hiru urte bururatu zitzaidan "3D argazkien" ideia, eta iaz patentatu nuen teknika hau.
Tokiko FSek sarekoetatik ikasi beharko luketen hurrengo gauza da metadatuak gailu bereizietan gordetzea sareko FSek makina bereizietan (metadatu zerbitzariak deiturikoak) gordetzen dituzten modu berean. Batez ere metadatuekin lan egiten duten aplikazioak daude, eta aplikazio hauek asko azkartu daitezke metadatuak errendimendu handiko biltegiratze gailu garestietan jarriz. FS+LVM konbinazioarekin, ezin izango duzu halako selektibitatea frogatu: LVM-k ez daki zer dagoen hari pasatu diozun blokean (datuak edo metadatuak).
Ez duzu etekin handirik lortuko zure maila baxuko LVM FSan ezartzeak FS + LVM konbinazioarekin alderatuta, baina oso ondo egin dezakezuna FS nahastea da, gero bere kodearekin lan egitea ezinezkoa izan dadin. ZFS eta Btrfs, gailu birtualekin ziztu bizian ibili zirenak, geruzak urratzeak sistema arkitekturaren arabera hiltzen duenaren adibide argiak dira. Beraz, zergatik naiz hau guztia? Gainera, ez dago zure behe-mailako LVM instalatu beharrik fitxategi-sisteman. Horren ordez, gailuak bolumen logikoetan batu behar dituzu maila altuan, sareko fitxategi-sistema batzuek makina ezberdinekin (biltegiratze-nodoak) egiten duten bezala. Egia da, hori nazkagarri egiten dute algoritmo txarrak erabiltzeagatik.
Algoritmo erabat ikaragarrien adibideak dira GlusterFS fitxategi-sistemako DHT itzultzailea eta Ceph fitxategi-sistemako CRUSH mapa deritzona. Ikusi nituen algoritmoetako batek ere ez ninduen asetzen sinpletasunari eta eskalagarritasun onari dagokionez. Beraz, aljebra gogoratu eta neuk asmatu behar nuen dena. 2015ean, hash funtzioen gaineko sortak esperimentatzen ari nintzela, niri egokitzen zitzaidan zerbait asmatu eta patentatu nuen. Orain esan dezaket hori guztia praktikan jartzeko saiakera arrakastatsua izan zela. Ikuspegi berrian ez dut eskalagarritasun arazorik ikusten.
Bai, azpibolumen bakoitzak egitura bereizi bat beharko du, esate baterako, memorian superbloke bat. Hau oso beldurgarria al da? Orokorrean, ez dakit nork "ozeanoa irakiten" eta ehunka mila gailu edo gehiagoko bolumen logikoak sortuko dituen tokiko makina batean. Norbaitek hau azaldu ahal badit, asko eskertuko dut. Bitartean, niretzat hau marketing astakeria da.
Kernel-blokeen gailuen azpisistemako aldaketek (adibidez, blk-mq itxurak) nola eragin zuten FS inplementatzeko eskakizunetan?
Ez zuten eraginik izan. Ez dakit zer gertatuko litzatekeen bloke geruzan FS berri bat diseinatzea beharrezkoa izango litzatekeen. Azpisistema hauen interakzio-interfazea oso eskasa da. Gidariaren aldetik, FS unitate mota berrien agerpenak soilik eragin beharko luke, bloke-geruza lehenik eta behin egokituko da, eta gero FS-a (reiser4rentzat horrek plugin berriak agertuko ditu).
Euskarri mota berrien agerpenak (adibidez, SMR edo SSDen nonahikotasuna) erronka berriak suposatzen al ditu fitxategi sistemaren diseinurako?
Bai. Eta hauek FS garatzeko ohiko pizgarriak dira. Erronkak desberdinak eta guztiz ustekabekoak izan daitezke. Esate baterako, I/O eragiketa baten abiadura datu baten tamainaren eta bere desplazamenduaren araberakoa den unitateen berri izan dut. Linux-en, non FS blokearen tamainak ezin duen orrialdearen tamaina gainditu, unitate horrek ez ditu bere gaitasun guztiak erakutsiko lehenespenez. Hala ere, zure fitxategi-sistema behar bezala diseinatuta badago, hortik askoz gehiago ateratzeko aukera dago.
Zenbat pertsona ari dira lanean Reiser4 kodearekin zu gain?
Nahi nukeena baino gutxiago, baina ez dut baliabide eskasia handirik ere bizi. Pozik nago Reiser4-ren garapen-erritmoarekin. Ez dut "zaldiak gidatuko" - hau ez da eremu egokia. Hemen, "isilago gidatzen baduzu, aurrera jarraituko duzu!" Fitxategi-sistema moderno bat nukleoaren azpisistema konplexuena da, diseinu okerreko erabakiek ondorengo giza-lanak desegin ditzakete.
Zerbait gauzatzeko boluntarioak eskainiz, beti bermatzen dut esfortzuak zalantzarik gabe emaitza zuzena ekarriko duela, behar larrietarako eska daitekeena. Ulertzen duzunez, ezin dira horrelako berme asko egon aldi berean. Aldi berean, ezin ditut jasan "zifrak" lotsagabeki erabilgarri ez den softwarearen "ezaugarriak" sustatzen dituztenak, ehunka erabiltzaile eta garatzaile engainatzen dituztenak, eta, aldi berean, nukleoen gailurretan eseri eta irribarre egiten dutenak.
Enpresaren batek Reiser4-ren garapenean laguntzeko prest agertu al da?
Bai, bazeuden halako proposamenak, barne. eta saltzaile nagusi batena. Baina horretarako beste herrialde batera joan behar izan nuen. Zoritxarrez, jada ez ditut 30 urte, ezin dut hautsi eta horrela utzi lehen txistuan.
Zein ezaugarri falta zaizkio gaur egun Reiser4-ri?
Ez dago "tamaina aldatzeko" funtziorik bolumen sinpleetarako, ReiserFS(v3)-n aurkitzen denaren antzekoa. Gainera, DIRECT_IO bandera duten fitxategi-eragiketak ez luke kalterik egingo. Ondoren, bolumen bat "azpibolumen semantiko"tan bereizi ahal izatea nahiko nuke, tamaina finkorik ez dutenak eta bolumen independente gisa munta daitezkeenak. Arazo hauek onak dira "benetako gauza"rekin probatu nahi duten hasiberrientzat.
Eta azkenik, sareko bolumen logikoak izatea nahiko nuke inplementazio eta administrazio sinpleekin (algoritmo modernoek hori ahalbidetzen dute dagoeneko). Baina Reiser4-k ez du inoiz izango RAID-Z, sasiak, espazio libreko cacheak, 128 biteko aldagaiak eta fitxategi-sistema batzuen garatzaileen artean ideia eskasiaren atzealdean sortu diren marketin zentzugabekeriak.
Behar litekeen guztia inplementa al daiteke pluginen bidez?
Horiek inplementatzen dituzten interfazeei eta pluginei (moduluak) soilik hitz egiten badugu, ez dena. Baina interfaze horietan erlazioak ere sartzen badituzu, orduan, besteak beste, goi-mailako polimorfismoen kontzeptuak izango dituzu, eta horiekin lehendik aurrera egin dezakezu. Imajinatu hipotetikoki objektuetara zuzendutako exekuzio-sistema bat izoztu duzula, instrukzio-erakuslearen balioa aldatu duzula X interfaze bera inplementatzen duen beste plugin batera seinalatzeko eta, ondoren, sistema desizoztu duzula exekutatzen jarrai dezan.
Azken erabiltzaileak ez badu horrelako "ordezkapen" bat nabaritzen, orduan sistemak zero-ordenako polimorfismoa duela esaten dugu X interfazean (edo sistema heterogeneoa dela X interfazean, hau da, gauza bera). Orain interfaze multzo bat ez ezik, harremanak ere badituzu (interfaze grafikoa), orduan maila altuagoko polimorfismoak sartu ditzakezu, sistemaren heterogeneotasuna ezaugarrituko dutenak jada edozein interfazeren "auzoan". Aspaldi sartu nuen halako sailkapen bat, baina, tamalez, ez zen inoiz gertatu.
Beraz, pluginen eta halako polimorfismo altuagoen laguntzaz, ezagutzen den edozein ezaugarri deskriba dezakezu, baita inoiz aipatu ere egin ez direnak “iragar” ere. Ezin izan dut hori zorrotz frogatu, baina ez dut oraindik kontraadibiderik ezagutzen. Orokorrean, galdera honek Felix Klein-en “Erlangen Programa” ekarri dit gogora. Garai batean geometria guztia aljebraren adar gisa irudikatzen saiatu zen (zehazki, taldeen teoria).
Orain galdera nagusira: nola doaz Reiser4-ren sustapenarekin muin nagusira? Azken elkarrizketan hitz egin zenuen fitxategi-sistema honen arkitekturari buruzko argitalpenik egon al zen? Zein garrantzitsua da galdera hau zure ikuspuntutik?
Oro har, hiru urte daramatzagu adar nagusian sartzea eskatzen. Reiser-ek tira eskaera egin zen hari publikoan egindako azken iruzkina erantzun gabe geratu zen. Beraz, galdera gehiago guztiak ez dira guretzat. Nik pertsonalki ez dut ulertzen zergatik "bat egin" behar dugun sistema eragile zehatz batean. Linux-en, argia ez zen ziri bat bezala bat egiten. Beraz, biltegi bereizi bat dago eta bertan hainbat adar-portu egongo dira OS desberdinetarako. Behar duenak dagokion ataka klonatu eta nahi duena egin dezake horrekin (lizentziaren barruan, noski). Beno, norbaitek behar ez badu, ez da nire arazoa. Puntu honetan, "Linux kernel nagusira sustatzeko" auzia finkatuta hartzea proposatzen dut.
FS arkitekturari buruzko argitalpenak garrantzitsuak dira, baina orain arte nire emaitza berrietarako denbora baino ez dut aurkitu, lehentasun handiagokotzat jotzen ditudanak. Beste gauza bat da matematikaria naizela, eta matematikan edozein argitalpen teoremen eta haien frogapenen laburpena da. Frogarik gabe han ezer argitaratzea gustu txarraren seinale da. FS-aren arkitekturari buruzko edozein baieztapen ondo frogatzen edo ezeztatzen badut, emaitza hori nahiko zaila izango da. Nork behar du? Horregatik, ziurrenik, denak bere forma zaharrean jarraitzen du - iturburu kodea eta iruzkinak.
Zer berri izan du Reiser4 azken urteotan?
Aspaldiko egonkortasuna gauzatu da azkenean. Agertu den azkenetako bat direktorio "ezabaezinak" ekarri zituen akats bat izan zen. Zailtasuna izen hash-talken atzealdean eta zuhaitz-nodo batean direktorio-erregistroen kokapen jakin batekin bakarrik agertzen zela zen. Hala ere, oraindik ezin dut Reiser4 produkziorako gomendatu: horretarako lan batzuk egin behar dituzu ekoizpen-sistemako administratzaileekin elkarrekintza aktiboarekin.
Azkenean, gure aspaldiko ideia ezartzea lortu genuen: transakzio eredu desberdinak. Aurretik, Reiser4-k Macdonald-Reiser eredu gogorreko kode bakarra exekutatu zuen. Horrek diseinu arazoak sortu zituen. Hain zuzen ere, transakzio-eredu horretan ezin dira argazkiak egin - "OVERWRITE SET" izeneko osagai atomiko batek hondatuko ditu. Reiser4-k hiru transakzio eredu onartzen ditu gaur egun. Horietako batean (Write-Anywhere), OVERWRITE SET osagai atomikoak sistema-orriak (diskoen bit-mapen irudiak, etab.) baino ez ditu barne hartzen, eta ezin dira “argazki” egin (oiloaren eta arrautzaren arazoa).
Beraz, orain irudiak ahalik eta modurik onenean gauzatu daitezke. Beste transakzio-eredu batean, aldatutako orrialde guztiak GAINDIZKETA MULTZOra soilik joaten dira (hau da, funtsean egunkari hutsa da). Eredu hau Reiser4 partizioen zatiketa azkarra dela salatu zutenentzat da. Orain eredu honetan zure partizioa ez da zatikatuko ReiserFS-rekin (v3) baino azkarrago. Dauden hiru modeloek, erreserba batzuekin, eragiketen atomotasuna bermatzen dute, baina atomotasuna galtzen duten eta sekzioaren osotasuna soilik gordeta duten ereduak ere erabilgarriak izan daitezke. Horrelako ereduak erabilgarri izan daitezke mota guztietako aplikazioetarako (datu-baseetarako, etab.), zeinek dagoeneko eginkizun horietako batzuk hartu dituzten. Oso erraza da eredu hauek Reiser4-ra gehitzea, baina nik ez nuen egin, inork ez zidalako galdetu, eta pertsonalki ez dut behar.
Metadatuen checksumak agertu ziren eta duela gutxi ispilu “ekonomiko”ekin osatu ditut (oraindik material ezegonkorra). Edozein blokeren checksumak huts egiten badu, Reiser4-k berehala irakurtzen du dagokion blokea erreplika gailutik. Kontuan izan ZFS eta Btrfs-ek ezin dutela hori egin: diseinuak ez du onartzen. Bertan "scrub" izeneko atzeko planoko eskaneatu prozesu berezi bat exekutatu behar duzu eta bloke problematikora iritsi arte itxaron. Programatzaileek modu figuratuan "makuluak" deitzen diete horrelako gertaerei.
Eta azkenik, bolumen logiko heterogeneoak agertu dira, ZFS, Btrfs, bloke-geruza eta baita printzipioz FS+LVM konbinazioek ere eman ezin duten guztia eskainiz - eskalatze paraleloa, O(1) disko-helbideen esleitzailea, azpibolumenen arteko datu migrazio gardena. Azken honek erabiltzaile-interfazea ere badu. Orain datu beroenak erraz eraman ditzakezu zure bolumeneko errendimendu handieneko diskora.
Horrez gain, posible da orri zikinak halako disko batera berehala garbitzea, eta horrela, sarritan fsync(2) deitzen duten aplikazioak nabarmen bizkortuko dira. Ohartu naiz bloke-geruzaren funtzionaltasunak, bcache izenekoak, ez duela inolako ekintza askatasunik ematen. Bolumen logiko berriak nire algoritmoetan oinarritzen dira (dagozkien patenteak daude). Softwarea nahiko egonkorra da dagoeneko, nahiko posible da probatu, errendimendua neurtzea, etab. Eragozpen bakarra da oraingoz bolumenaren konfigurazioa eskuz eguneratu eta nonbait gorde behar duzula.
Orain arte nire ideiak ehuneko 10ean inplementatu ahal izan ditut. Hala ere, zailena iruditzen zitzaidanean lortu dut: bolumen logikoak konektatzea reiser4-n atzeratutako ekintza guztiak egiten dituen flash prozedura batekin. Hau guztia "format41" adar esperimentalean dago oraindik.
Reiser4-k xfstestak gainditzen al ditu?
Niri behintzat egin zidan azken bertsioa prestatzen ari nintzenean.
Printzipioz posible al da Reiser4 sare (kluster) FS bihurtzea pluginak erabiliz?
Posible da, eta baita beharrezkoa ere! Behar bezala diseinatutako tokiko fitxategi-sistema batean oinarritutako sare-fitxategi bat sortzen baduzu, emaitza oso ikusgarria izango da! Sareko FS modernoetan, ez nago pozik backend biltegiratze maila bat egotearekin, edozein tokiko FS erabiliz inplementatzen dena. Maila honen existentzia guztiz justifikatu gabea da. Sare FSak bloke geruzarekin zuzenean elkarreragin behar du, eta ez dio tokiko FSari eskatu beste zerbitzu-fitxategirik sortzeko!
Orokorrean, fitxategi sistema lokaletan eta sarean banatzea gaiztoarena da. Duela hogeita hamar urte erabiltzen ziren algoritmoen inperfekziotik sortu zen, eta horien ordez oraindik ez da ezer proposatu. Hau da, halaber, beharrezkoak ez diren software osagai ugari agertzearen arrazoia (hainbat zerbitzu, etab.). Modu onean, FS bakarra egon beharko litzateke nukleoaren modulu moduan eta makina bakoitzean instalatutako erabiltzaile-utilitate multzo bat - cluster nodo bat. FS hau lokala eta sarekoa da. Eta ezer gehiago!
Linux-en Reiser4-rekin ezer ez bada funtzionatzen, FreeBSDrako FS bat eskaini nahiko nuke (aurreko elkarrizketa baten aipua: “...FreeBSD... sustrai akademikoak ditu... Eta horrek esan nahi du probabilitate handiarekin dugula hizkuntza komun bat aurkituko du garatzaileekin”)?
Beraz, jakin berri dugunez, dena primeran funtzionatu du jada Linux-ekin: Reiser4 ataka bereizi bat dago gure biltegiaren adar nagusi baten moduan. Ez naiz ahaztu FreeBSD! Eskaintza! Prest nago FreeBSDren barruak ondo ezagutzen dituztenekin elkarlan estuan lan egiteko. Bide batez: haien komunitatetik asko gustatzen zaidana da hango erabakiak aditu independenteen kontseilu eguneratu batek hartzen dituela, eta horrek ez dauka zerikusirik pertsona iraunkor baten gobernuaren iruzurrarekin.
Nola baloratzen duzu gaur egun Linux erabiltzaileen komunitatea? "Pop"agoa bihurtu al da?
Nire lanaren izaera ikusita, nahiko zaila egiten zait hori baloratzea. Gehienetan erabiltzaileak akatsen txostenak eta atala konpontzeko eskaerak etortzen zaizkit. Erabiltzaileak erabiltzaile gisa. Batzuk jakintsuagoak dira, beste batzuk gutxiago. Denak berdin tratatzen dira. Tira, erabiltzaileak nire argibideak jaramonik ez baditu, barkatu: ez ikusiaren agindua ere sartuko da nire aldetik.
Posible al da hurrengo bost-hamar urteetarako fitxategi-sistemen garapena aurreikustea? Zeintzuk dira zure ustez FS garatzaileek izan ditzaketen erronka nagusiak?
Bai, ez da zaila horrelako aurreikuspen bat egitea. Aspalditik ez dago fitxategi-sistemen garapenik goran. Horrelako itxura baino ez da sortzen. Fitxategi-sistema lokalen garatzaileek diseinu txarrarekin lotutako arazoak izan zituzten. Oharra egin behar da hemen. Ez dut kodearen "biltegiratzea", "mizkatu" eta porturatzea deritzona garapena eta garapena denik. Eta ez dut "Btrfs" izeneko gaizki-ulertzea garapen gisa sailkatzen lehen azaldu ditudan arrazoiengatik.
Adabaki bakoitzak bere arazoak okerrera egiten du. Bueno. eta beti daude hainbat motatako "ebanjelistak" zeinentzat "denak funtzionatzen duen". Funtsean, hitzaldiak saltatzen dituzten eskola-umeak eta ikasleak dira. Imajinatu: berarentzat balio du, baina irakasleak ez. Zein adrenalina igoera den hau! Nire ikuspuntutik, kalterik handiena Btrfs-en ezaugarri zoragarriak era guztietako geruzatan, hala nola, systemd, docker, etab. - honek metastasien antza du dagoeneko.
Saia gaitezen orain bost-hamar urterako iragarpena egiten. Dagoeneko laburki zerrendatu dut Reiser4-en egingo duguna. Upstream tokiko FS garatzaileen erronka nagusia izango da (bai, dagoeneko bihurtu da) soldata baten truke lan duin bat egiteko ezintasuna. Datuak biltegiratzeko ideiarik gabe, zorigaiztoko VFS, XFS eta ext4 hauek adabakitzen saiatzen jarraituko dute. VFS-ren egoerak bereziki komiko dirudi aurrekari honetan, sukaldaririk ez dagoen eta sukaldaririk espero ez den jatetxe baten modernizazio amorratua gogorarazten duena.
Orain VFS kodeak, inolako baldintzarik gabe, hainbat memoria-orri blokeatzen ditu aldi berean eta azpian dagoen FS-a haietan jarduteko gonbidatzen du. Hau Ext4-ren errendimendua hobetzeko sartu zen ezabatze-eragiketetan, baina erraz ulertzen denez, aldibereko blokeo hori guztiz bateraezina da transakzio-eredu aurreratuekin. Hau da, ezingo duzu nukleoan fitxategi sistema adimendun baterako laguntza besterik gehitu. Ez dakit zein den Linux-en beste eremu batzuetan dagoen egoera, baina fitxategi-sistemei dagokienez, hemengo garapenik nekez izango da bateragarria Torvaldek praktikan egiten duen politikarekin (proiektu akademikoak kanporatu egiten dira, eta iruzurgileak). ez dakit zer B-zuhaitz bat, konfiantzazko kreditu amaigabeak igortzen diren). Hori dela eta, usteltze geldorako bidea ezarri zen. Noski, indar guztiekin saiatuko dira «garapen» gisa pasatzen.
Gainera, fitxategi-sistemen "zaindariek", "biltegiratzetik" bakarrik ezin duzula asko irabazi konturatuta, negozio errentagarriago batean saiatuko dira. Hauek dira, oro har, banatutako fitxategi sistemak eta birtualizazioa. Beharbada, modan dagoen ZFS beste leku batera eramango dute oraindik existitzen ez den tokira. Baina, ibaian gorako FS guztiak bezala, Urte Berriko zuhaitz baten antza du: gainean beste gauza txiki batzuk zintzilikatzen badituzu, orduan ezin duzu sakondu. Onartzen dut ZFSn oinarritutako enpresa-sistema serio bat eraikitzea posible dela, baina orain etorkizunari buruz eztabaidatzen ari garenez, zoritxarrez esan dezaket ZFS-k itxaropenik gabe dagoela zentzu honetan: beren gailu birtualekin, mutilek oxigenoa moztu dute. beraiek eta etorkizuneko belaunaldiek aurrerago garatzeko. ZFS iraganeko gauza bat da. Eta ext4 eta XFS ez dira atzo bezperan ere.
Bereiz aipatzea komeni da "Hurrengo belaunaldiko Linux fitxategi-sistema" kontzeptua. Hau guztiz politikoa eta marketin-proiektu bat da, nolabait esateko, Linux-en fitxategi-sistemen etorkizuna karaktere zehatzen atzean jartzeko aukera izateko. Kontua da Linux "dibertsiorako" izaten zela. Baina orain batez ere dirua irabazteko makina bat da. Ahal den guztian eginak daude. Esaterako, oso zaila da software produktu on bat sortzea, baina "garatzaile" adimentsuak aspaldi konturatu dira ez dagoela batere estutu beharrik: arrakastaz saldu dezakezu existitzen ez den softwarea, publiko mota guztietan iragarri eta sustatu zena. gertaerak - gauza nagusia da aurkezpen-diapositibak "ezaugarri" gehiago eduki behar dituela.
Fitxategi-sistemak ezin hobeak dira horretarako, hamar urtez segurtasunez negoziatu dezakezulako emaitzarekin. Beno, gero norbaitek emaitza horren faltagatik kexatzen bada, orduan ez du ezer ulertzen fitxategi-sistemei buruz! Horrek finantza-piramide bat ekartzen du gogora: goian nahaspila hau hasi zuten abenturazaleak daude, eta “zortea” izan zuten gutxi horiek: “dibidenduak erretiratu” zituzten, hau da. garapenerako dirua jaso, kudeatzaile gisa ondo ordaindutako lana lortu, biltzarretan “agertu” zen, etab.
Segidan datoz “zorte txarra” dutenak: galerak zenbatuko dituzte, erabilezin den software produktu bat produkzioan hedatzeak dakartzan ondorioei aurre egingo diete, “etab. Askoz gehiago dira. Beno, piramidearen oinarrian garatzaileen masa izugarria dago alferrikako kodea "zerratzen". Galtzaile handienak dira, galdutako denbora ezin baita itzuli. Halako piramideak oso onuragarriak dira Torvalds eta bere kideentzat. Eta piramide horiek zenbat eta gehiago, orduan eta hobeto beraientzat. Halako piramideak elikatzeko, edozer har daiteke muinean. Jakina, jendaurrean kontrakoa esaten dute. Baina ez dut hitzen arabera epaitzen, ekintzen arabera baizik.
Beraz, "fitxategi-sistemen etorkizuna Linux-en" oso sustaturiko beste software bat da, baina nekez erabil daitekeena. Btrfs-en ondoren, probabilitate handiarekin, halako "etorkizun" baten lekua Bcachefsek hartuko du, hau da, Linux bloke-geruza fitxategi-sistema batekin zeharkatzeko beste saiakera bat (adibide txar bat kutsakorra da). Eta tipikoa dena: Btrfs-en dauden arazo berdinak daude. Denbora luzez hau susmatu nuen, eta, nolabait, ezin izan nuen eutsi eta kodea aztertu - egia da!
Bcachefs eta Btrfs-en egileek, beren FS sortzean, aktiboki erabili zituzten besteen iturriak, haiei buruz ezer gutxi ulertuz. Egoerak oso gogorarazten du haurrentzako "telefono hautsi" jolasa. Eta gutxi gorabehera imajinatu dezaket kode hau nukleoan nola sartuko den. Egia esan, inork ez ditu ikusiko "arrastoak" (denek zapalduko dituzte gero). Kodearen estiloari, existitzen ez diren urraketen akusazioei eta abarrei buruzko hainbat zalantzaren ondoren, egilearen "leialtasunari" buruzko ondorioa aterako da, beste garatzaile batzuekin nola "interakzionatzen" duen eta horrek guztiak nola arrakasta duen. gero korporazioei saltzeko.
Azken emaitza ez du inori interesatuko. Duela hogei urte, beharbada, interesatuko zitzaidakeen, baina orain galderak beste era batera planteatzen dira: posible izango al da hori bultzatzea, datozen hamar urteetan zenbait pertsona lanean egon daitezen. Eta, tamalez, ez da ohitura azken emaitzaz galdetzea.
Oro har, gomendatuko nuke zure fitxategi-sistema hutsetik berrasmatzen hastea. Finantza inbertsio garrantzitsuak ere ez direlako nahikoa izango hamar urtean zerbait lehiakorra lortzeko. Noski, proiektu serioez ari naiz, eta ez nukleora "bultzatu" nahi direnez. Beraz, adierazteko modu eraginkorragoa da benetako garapenekin bat egitea, gu bezala. Hori, noski, ez da erraza egiten, baina hori da goi mailako edozein proiekturen kasua.
Lehenik eta behin, eskainiko dizudan arazoa modu independentean gainditu beharko duzu. Horren ondoren, zure asmoen larritasunaz sinetsita, laguntzen hasiko naiz. Tradizionalki, gure garapenak bakarrik erabiltzen ditugu. Salbuespenak konpresio algoritmoak eta hash funtzio batzuk dira. Ez ditugu garatzaileak bidaltzen kongresuetara bidaiatzera, eta gero ez gara esertzen eta besteen ideiak konbinatzen (“agian zer gertatuko den”), startup gehienetan ohikoa den bezala.
Guk garatzen ditugu algoritmo guztiak. Gaur egun, datuak biltegiratzeko zientziaren alderdi aljebraiko eta konbinatorioak interesatzen zaizkit. Bereziki, eremu finituak, asintotikoak, desberdintasunen froga. Programatzaile arruntentzat ere badago lana, baina berehala ohartarazi behar dizut: "beste FS bat begiratu eta gauza bera egiteko" iradokizun guztiak ez dira aintzat hartzen. Linux-ekin VFS bidez integratzeko helburu duten adabakiak ere bertara joango dira.
Beraz, ez dugu arrastorik, baina ulertzen dugu nora mugitu behar dugun, eta konfiantza dugu norabide hori egokia dela. Ulermen hau ez zen zerutik mana moduan etorri. Gogorarazten dizut 29 urteko garapen esperientzia dugula atzean, hutsetik idatzitako bi fitxategi-sistema. Eta datuak berreskuratzeko utilitate kopuru bera. Eta hau asko da!
Iturria: opennet.ru