La dua intervjuo kun Eduard Shishkin, ellaboranto de la dosiersistemo Reiser4, estis publikigita.
Por komenci, bonvolu memorigi legantojn kie kaj por kiu vi laboras.
Mi laboras kiel Ĉefa Stokada Arkitekto ĉe Huawei Technologies, Germana Esplorcentro. En la fako de virtualigo mi traktas diversajn aspektojn de datumstokado. Miaj agadoj ne rilatas al specifa operaciumo.
Ĉu vi nuntempe engaĝiĝas al la ĉefa kernbranĉo?
Tre malofte, kaj nur se mia dunganto postulas ĝin. La lastan fojon estis antaŭ ĉirkaŭ tri jaroj, mi sendis diakilojn por pliigi la trairon por stokado dividita en gastigantoj uzante la 9p-protokolon (alia nomo por ĉi tiu komerco estas VirtFS). Unu grava noto devas esti farita ĉi tie: kvankam mi laboras kun Linukso delonge, mi neniam estis ŝatanto de ĝi, tio estas, mi "siras egale", kiel ĉe ĉio alia. Precipe, se mi rimarkas difekton, mi povas montri ĝin maksimume unufoje. Kaj por ke vi tiam povu sekvi iun kaj persvadi ilin - tio ne okazos.
Mi memoras la lastan fojon, antaŭ dek jaroj, vi estis sufiĉe kritika de la kerna evolustilo. El via (aŭ eble kompania) vidpunkto, ĉu io ŝanĝiĝis, ĉu la komunumo fariĝis pli respondema aŭ ne? Se ne, kiu laŭ vi kulpas?
Mi neniam vidis ŝanĝojn por pli bone. La ĉefa problemo de la komunumo estas la anstataŭigo de scienco per politikaj teknologioj, personaj rilatoj, plimulta opinio, popolismo, konsiloj de "internaj voĉoj", putraj kompromisoj, io ajn alia ol scienco. Komputiko, kion ajn oni povas diri, estas antaŭ ĉio ekzakta scienco. Kaj se iu komencas proklami sian propran valoron por 2x2, malsama ol 4, sub la flago "Linuksa maniero", aŭ sub iu alia flago, tiam ĉi tio verŝajne ne alportos ion alian ol damaĝon.
Ĉiuj problemoj estas ĉefe pro la nekompetenteco kaj manko de edukado de tiuj, kiuj decidas. Se administranto estas nekompetenta, li ne kapablas fari objektivan, adekvatan decidon. Se li ankaŭ estas nekulturita, li ne kapablas trovi kompetentan specialiston, kiu donos al li la ĝustajn konsilojn. Kun alta probablo, la elekto falos sur skamisto, kiu diras "ŝajne ĝustaj aferoj". Korupta medio ĉiam disvolviĝas ĉirkaŭ nekompetentaj solaj gvidantoj. Krome, la historio ne konas esceptojn ĉi-rilate, kaj la komunumo estas la plej klara konfirmo pri tio.
Kiel vi taksas la progreson en la disvolviĝo de Btrfs? Ĉu ĉi tiu FS forigis infanajn malsanojn? Kiel vi poziciigas ĝin por vi mem - kiel FS "por hejmo" aŭ ankaŭ por kompania uzo?
Mi ne forigis ĝin. Ĉio, kion mi menciis antaŭ 11 jaroj, estas ankoraŭ aktuala hodiaŭ. Unu el la problemoj kun Btrfs, kiu faras ĝin maltaŭga por seriozaj bezonoj, estas la problemo de libera spaco. Mi eĉ ne parolas pri tio, ke la uzanto estas petata kuri al la vendejo por nova disko en situacioj, kie iu ajn alia FS montrus multe da libera spaco sur la diskparto. La nekapablo plenumi operacion sur logika volumeno pro manko de libera spaco ankaŭ ne estas la plej malbona afero. La plej malbona afero estas, ke senprivilegia uzanto preskaŭ ĉiam povas preterpasi iujn ajn diskkvotojn, senigi ĉiujn je libera spaco en sufiĉe mallonga tempo.
Ĝi aspektas tiel (provita por Linukso-kerno 5.12). Skripto estas lanĉita sur ĵus instalita sistemo, kiu en buklo kreas dosierojn kun certaj nomoj en la hejma dosierujo, skribas datumojn al ili ĉe certaj ofsetoj, kaj poste forigas ĉi tiujn dosierojn. Post minuto da rulado de ĉi tiu skripto, nenio nekutima okazas. Post kvin minutoj, la parto de okupita spaco sur la vando iomete pliiĝas. Post du-tri horoj ĝi atingas 50% (kun komenca valoro de 15%). Kaj post kvin aŭ ses horoj da laboro, la skripto kraŝas kun la eraro "ne estas libera spaco sur la sekcio." Post ĉi tio, vi ne plu povas skribi eĉ 4K-dosieron al via sekcio.
Interesa situacio okazas: vi finfine skribis nenion al la vando, kaj la tuta libera spaco (ĉirkaŭ 85%) malaperis ie. Analizo de sekcio submetata al tia atako rivelos multajn arbnodojn enhavantajn nur unu objekton (objekto ekipita per ŝlosilo), plurajn bajtojn en grandeco. Tio estas, la enhavo, kiu antaŭe okupis 15% de la diskospaco, montriĝis egale "ŝmiris" sur la tuta subdisko tiel ke estas nenie por skribi novan dosieron, ĉar ĝia ŝlosilo estas pli granda ol ĉiuj ekzistantaj, kaj la libera. blokoj sur la vando elĉerpiĝis.
Krome, ĉi tio ĉio okazas jam ĉe la baza agordo Btrfs (sen iuj momentfotoj, subvolumoj, ktp.), kaj ne gravas kiel vi decidas konservi dosierkorpojn en tiu FS (kiel "fragmentoj" en arbo, aŭ kiel etendaĵoj). de neformatitaj blokoj) - la fina rezulto estos la sama.
Vi ne povos submeti aliajn kontraŭfluajn dosiersistemojn al tia atako (ne gravas kion ili diras al vi). Mi klarigis la kaŭzon de la problemo antaŭ longe: tio estas kompleta perversiĝo de la B-arba koncepto en Btrfs, kiu ebligas, ke ĝi spontane aŭ intence degeneru. Precipe, sub certaj ŝarĝoj, via dosiersistemo senĉese "disfalos" dum funkciado memstare, sen ekstera helpo. Estas klare, ke ĉiaj "premantaj" fonaj procezoj savos la tagon nur sur individuaj labortabloj.
Sur kolektivaj serviloj, atakanto ĉiam povos "antaŭeniri" ilin. La administranto de la sistemo eĉ ne povos determini, kiu ĝuste ĉikanis lin. La plej rapida maniero ripari ĉi tiun problemon en Btrfs estas restarigi la strukturon de regula B-arbo, t.e. restrukturi la diskoformaton kaj reverki signifajn partojn de la Btrfs-kodo. Ĉi tio daŭros 8-10 jarojn, inkluzive de senararigado, kondiĉe ke la programistoj strikte sekvis la originalajn artikolojn pri la koncernaj algoritmoj kaj datumstrukturoj, kaj ne ludis la ludon "rompita telefono", kiel estas kutima (kaj kuraĝigita) en la "Linukso". vojo”.
Ĉi tie ni ankaŭ devas aldoni la tempon necesan por ke programistoj komprenu ĉion ĉi. Ĉi tie ĝi fariĝas pli malfacila. Ĉiukaze, 10 jaroj ne sufiĉis por ke ili komprenu. Nu, ĝis tiam vi ne povas esperi miraklon. Ĝi ne okazos en la formo de munta opcio "pri kiu vi kaj mi ne sciis", aŭ en la formo de flikaĵo, kiu estas "nur afero de komerco" por prepari. Por ĉiu tia rapida "riparo" mi prezentos novan scenaron de degenero. B-arboj estas unu el miaj plej ŝatataj temoj, kaj mi devas diri, ke ĉi tiuj strukturoj ne toleras liberecojn per si mem!
Kiel mi poziciigas Btrfs por mi mem? Kiel io, kio absolute ne povas esti nomita dosiersistemo, des malpli uzata. Ĉar, laŭdifine, la FS estas OS-subsistemo respondeca por la efika administrado de la rimedo "diskospaco", kiun ni ne vidas en la kazo de Btrfs. Nu, imagu, ke vi venis al la vendejo por aĉeti horloĝon por ne malfrui al la laboro, kaj anstataŭ horloĝo ili vendis al vi elektran kradon kun tempigilo por maksimume 30 minutoj. Do, la situacio kun Btrfs estas eĉ pli malbona.
Trarigardante dissendolistojn, mi ofte renkontas la deklaron, ke efike administri diskspacon ne plu gravas pro la malmultekosteco de diskoj. Ĉi tio estas kompleta sensencaĵo. Sen efika administranto de diskspaco, la OS fariĝos vundebla kaj neuzebla. Sendepende de la kapablo de la diskoj sur via maŝino.
Mi ŝatus peti komenton pri la ĉesigo de Btrfs-subteno en RHEL.
Estas nenio speciala por komenti ĉi tie, ĉio estas tre klara. Ili ankaŭ havis ĝin kiel "teknologian antaŭprezenton". Do, mi ne trapasis ĉi tiun tre "antaŭrigardon". Ne lasu ĉi tiun etikedon pendi eterne! Sed ili ne povas lanĉi misan laŭdezajnan produkton kun plena subteno. RHEL estas entrepreno, tio estas preskribitaj varo-mono rilatoj. Red Hat ne povas ĉikani uzantojn kiel ili faras en la dissendolisto Btrfs. Imagu nur la situacion: kliento, kiu pagis sian malfacile gajnitan monon por la disko kaj ankaŭ vi por subteno, volas kompreni, kien lia diskospaco iris post kiam li skribis nenion. Kion vi respondos al li al ĉi tio?
Plue. La klientoj de Red Hat inkluzivas konatajn grandajn bankojn kaj interŝanĝojn. Imagu, kio okazus se ili estus submetitaj al DoS-atakoj bazitaj sur la menciita vundebleco en Btrfs. Kiu laŭ vi respondecas pri tio? Al tiuj, kiuj fingromontros la linion de la GPL-licenco, kie estas skribite, ke la aŭtoro respondecas pri nenio, mi tuj diros: "kaŝu ĝin!" Ruĝa Ĉapelo respondos, kaj tiel, ke ĝi ne ŝajnos sufiĉe! Sed mi scias, ke Red Hat ne alfrontas tian problemon, pro ilia precipe forta teamo de QA-inĝenieroj kun kiuj mi havis la ŝancon proksime labori en mia tempo.
Kial iuj kompanioj daŭre subtenas Btrfs en siaj entreprenaj produktoj?
Bonvolu noti, ke la prefikso "entrepreno" en la produktonomo ne signifas multon. Entrepreno estas mezuro de respondeco enigita en la kontrakta rilato kun la kliento. Mi konas nur unu entreprenon bazitan sur GNU/Linukso - RHEL. Ĉio alia, laŭ mia vidpunkto, estas nur prezentita kiel entrepreno, sed ne estas tia. Kaj finfine, se estas postulo por io, tiam ĉiam estos provizo (en nia kazo, ĉi tio estas la menciita "subteno"). Estas postulo por absolute ĉio, inkl. kaj neuzebla programaro. Kiel tia postulo formiĝas kaj kiu nutras ĝin estas alia temo.
Do, mi ne saltus al iujn konkludojn post kiam oni disvastiĝas, ke Facebook deplojis Btrfs sur siaj serviloj. Cetere, mi rekomendus zorge konservi la adresojn de tiuj serviloj sekretaj pro la supraj kialoj.
Kial oni faris tiom da penado por purigi la XFS-kodon lastatempe? Post ĉio, komence ĉi tio estas triaparta dosiersistemo, kaj ext4 estas stabila dum longa tempo kaj havas kontinuecon de antaŭaj same stabilaj versioj. Kian intereson havas Red Hat en XFS? Ĉu havas sencon aktive evoluigi du dosiersistemojn, kiuj estas similaj en celo - ext4 kaj XFS?
Mi ne memoras, kio motivigis tion. Estas tute eble, ke la iniciato venis de klientoj de Red Hat. Mi memoras, ke tiaspeca esplorado estis farita: sur iuj dosiersistemoj de kontraŭflue, giganta nombro da objektoj estis kreitaj sur altnivelaj diskoj de la nova generacio. Laŭ la rezultoj, XFS kondutis pli bone ol ext4. Do ili komencis reklami ĝin kiel la plej promesplena. Ĉiukaze, mi serĉus nenion sensacian ĉi tie.
Por mi, estas kvazaŭ ili anstataŭigis alenon per sapo. Ne utilas disvolvi ext4 kaj XFS. Ambaŭ paralele kaj iu ajn el ili por elekti. Nenio bona venos el ĉi tio. Kvankam, en la naturo ofte estas situacioj, kiam estas multe da potencialo por kresko, sed ne estas loko por kreski. En ĉi tiu kazo, aperas diversaj bizare malbelaj novaj kreskaĵoj, al kiuj ĉiuj montras la fingron ("Ho, rigardu, kion vi ne vidos en ĉi tiu vivo!").
Ĉu vi pensas, ke la temo de tavolo-malobservo estis solvita (en negativa signifo) kun la apero de ĉifradaj funkcioj en ext4, F2FS (sen mencii RAID en Btrfs)?
Ĝenerale, la enkonduko de iuj niveloj kaj decido pri ilia ne-malobservo estas kutime afero de politiko, kaj mi ne entreprenas komenti ion ajn ĉi tie. La objektivaj aspektoj de tavola malobservo estas malmulte interesaj por iu ajn, sed ni povas konsideri kelkajn el ili uzante la ekzemplon de malobservo "de supre", nome, la efektivigo en la FS de funkcieco, kiu jam ekzistas sur la bloka tavolo. Tia "malobservo" estas pravigita kun nur maloftaj esceptoj. Por ĉiu tia kazo, vi unue devas pruvi du aferojn: ke ĝi vere bezonas, kaj ke la dezajno de la sistemo ne estos damaĝita per tio.
Ekzemple, spegulado, kiu tradicie estis agado por la bloktavolo, havas sencon efektivigi ĉe la dosiersistemo-nivelo. Pro malsamaj kialoj. Ekzemple, "silenta" datuma korupto (bit putro) okazas sur diskiloj. Ĉi tio estas kiam la aparato funkcias ĝuste, sed la blokdatenoj estas neatendite damaĝitaj sub la influo de malmola gama-kvanto elsendita de malproksima kvazaro, ktp. La plej malbona afero estas se ĉi tiu bloko montriĝas esti FS-sistembloko (superbloko, bitmap-bloko, stokado-arba nodo, ktp.), ĉar tio certe kondukos al kerna paniko.
Bonvolu noti, ke la speguloj ofertitaj de la bloktavolo (tiel nomata RAID 1) ne savos vin de ĉi tiu problemo. Nu, vere: iu devus kontroli la ĉeksumojn kaj legi la kopion en kazo de malsukceso? Krome, havas sencon speguli ne nur ĉion, sed nur la metadatenojn. Iuj gravaj datumoj (ekzemple, ruleblaj dosieroj de kritikaj aplikoj) povas esti stokitaj kiel metadatenoj. En ĉi tiu kazo, ili ricevas la samajn garantiojn de sekureco. Estas senco konfidi la protekton de la ceteraj datumoj al aliaj subsistemoj (eble eĉ uzantaj aplikaĵoj) - ni disponigis ĉiujn necesajn kondiĉojn por tio.
Tiaj "ekonomiaj" speguloj havas rajton ekzisti, kaj ili povas esti organizitaj nur efike sur la dosiersistemo-nivelo. Alie, tavoliga malobservo malordigas la subsistemon per duplikata kodo pro iuj mikroskopaj avantaĝoj. Frapa ekzemplo de tio estas la efektivigo de RAID-5 uzante FS. Tiaj solvoj (propra RAID / LVM en la dosiersistemo) mortigas ĉi-lastan en arkitekturaj terminoj. Oni devas ankaŭ rimarki ĉi tie, ke tavola malobservo estas "metita en fluo" de diversaj specoj de merkataj skamantoj. Manke de iuj ideoj, al la subsistemoj aldoniĝas funkcieco delonge efektivigita ĉe najbaraj niveloj, ĉi tio estas prezentita kiel nova ekstreme utila trajto kaj aktive puŝita.
Reiser4 estis akuzita je malobservo de la niveloj "de malsupre". Surbaze de tio, ke la dosiersistemo ne estas monolita, kiel ĉiuj aliaj, sed modula, oni faris nepruvitan supozon, ke ĝi faras tion, kion la supra nivelo (VFS) devus fari.
Ĉu eblas paroli pri la morto de ReiserFS v3.6 kaj, ekzemple, JFS? Lastatempe ili preskaŭ ne ricevis atenton en la kerno. Ĉu ili estas malnoviĝintaj?
Ĉi tie ni devas difini, kion signifas la morto de programaro. Unuflanke, ili estas sukcese uzataj (por tio ili ja estis kreitaj), kio signifas, ke ili vivas. Aliflanke, mi ne povas paroli por JFS (mi ne scias multon), sed ReiserFS (v3) estas tre malfacile adaptebla al novaj tendencoj (provita en la praktiko). Ĉi tio signifas, ke estonte programistoj atentos ne al ĝi, sed al tiuj, kiuj estas pli facile adapteblaj. De ĉi tiu flanko rezultas, ke, ve, ĝi estas morta laŭ arkitekturaj terminoj. Mi tute ne manipulus la koncepton de "morale malnoviĝinta". Ĝi validas bone, ekzemple, por vestaro, sed ne por softvaraĵoj. Estas koncepto de malsupereco kaj supereco en io. Mi povas absolute diri, ke ReserFS v3 nun estas malsupera al Reiser4 en ĉio, sed en iuj specoj de laborŝarĝo ĝi estas pli alta ol ĉiuj aliaj kontraŭfluaj FS-oj.
Ĉu vi scias pri la evoluo de FS Tux3 kaj HAMMER/HAMMER2 (FS por DragonFly BSD)?
Jes, ni scias. En Tux3 mi iam interesiĝis pri la teknologio de iliaj momentfotoj (la tiel nomataj "versiaj montriloj"), sed en Reiser4 ni plej verŝajne iros alian vojon. Mi delonge pensas pri subteno de momentfotoj kaj ankoraŭ ne decidis kiel efektivigi ilin por simplaj Reiser4-volumoj. La fakto estas, ke la nova "maldiligenta" referenca nombrilo tekniko proponita de Ohad Rodeh nur funkcias por B-arboj. Ni ne havas ilin. Por tiuj datumstrukturoj, kiuj estas uzataj en Reiesr4, "maldiligentaj" nombriloj ne estas difinitaj - por enkonduki ilin, necesas solvi iujn algoritmajn problemojn, kiujn neniu ankoraŭ akceptis.
Laŭ HAMMER: Mi legis artikolon de la kreinto. Ne interesiĝas. Denove, B-arboj. Ĉi tiu datumstrukturo estas senespere malmoderna. Ni forlasis ĝin en la lasta jarcento.
Kiel vi taksas la kreskantan postulon je retgrupoj FS kiel CephFS / GlusterFS / ktp? Ĉu ĉi tiu postulo signifas ŝanĝon en la prioritatoj de programistoj al reto FS kaj nesufiĉa atento al loka FS?
Jes, tia ŝanĝo en prioritatoj okazis. La evoluo de lokaj dosiersistemoj stagnis. Ve, fari ion gravan por lokaj volumoj nun estas sufiĉe malfacila kaj ne ĉiuj povas fari ĝin. Neniu volas investi en ilia evoluo. Ĉi tio estas proksimume la sama kiel peti komercan organizon asigni monon por matematika esplorado - sen ia entuziasmo ili demandos vin kiel vi povas gajni monon per nova teoremo. Nun loka FS estas io, kio magie aperas "el la skatolo" kaj "ĉiam devus funkcii", kaj se ĝi ne funkcias, ĝi kaŭzas neadresitan grumblon kiel: "Jes, kion ili pensas!"
Tial la manko de atento al lokaj FS, kvankam estas ankoraŭ multe da laboro en tiu areo. Kaj jes, ĉiuj turnis sin al distribuita stokado, kiu estas konstruita surbaze de jam ekzistantaj lokaj dosiersistemoj. Ĝi estas tre moda nun. La frazo "Big Data" kaŭzas adrenalinon por multaj, asociante ĝin kun konferencoj, laborrenkontiĝoj, grandaj salajroj, ktp.
Kiom racie estas principe efektivigi la retan dosiersistemon en kernspaco prefere ol en uzantspaco?
Tre akceptebla aliro kiu ankoraŭ ne estis efektivigita ie ajn. Ĝenerale, la demando pri kiu spaco reta dosiersistemo devus esti efektivigita estas "dutranĉa glavo". Nu, ni rigardu ekzemplon. La kliento registris datumojn sur fora maŝino. Ili falis en ŝian paĝan kaŝmemoron en formo de malpuraj paĝoj. Ĉi tio estas la laboro por "maldika enirejo" retdosiersistemo en kernspaco. Tiam la operaciumo pli aŭ malpli frue petos vin skribi tiujn paĝojn al disko por liberigi ilin. Tiam la IO-sendanta (sendanta) reto FS-modulo eniras en ludon. Ĝi determinas al kiu servila maŝino (servila nodo) ĉi tiuj paĝoj iros.
Tiam la reto stako transprenas (kaj, kiel ni scias, ĝi estas efektivigita en kernspaco). Poste, la servila nodo ricevas tiun pakaĵeton kun datumoj aŭ metadatenoj kaj instrukcias la backend-stokan modulon (t.e., la loka FS kiu funkcias en kernspaco) registri ĉion ĉi. Do, ni reduktis la demandon al kie la "sendanta" kaj "ricevanta" moduloj devus funkcii. Se iu el tiuj moduloj funkcias en uzantspaco, tio neeviteble kondukos al kuntekstoŝanĝo (pro la bezono uzi kernservojn). La nombro da tiaj ŝaltiloj dependas de la efektivigdetaloj.
Se ekzistas multaj tiaj ŝaltiloj, tiam stokada trairo (I/O-efikeco) malpliiĝos. Se via backend-stokado konsistas el malrapidaj diskoj, tiam vi ne rimarkos signifan falon. Sed se vi havas rapidajn diskojn (SSD, NVRAM, ktp.), tiam kunteksta ŝanĝado jam fariĝas "botelo" kaj, ŝparante kunteksta ŝanĝado, rendimento povas esti signife pliigita. La norma maniero ŝpari monon estas movi modulojn en kernspacon. Ekzemple, ni trovis, ke movi la 9p-servilon de QEMU al la kerno sur la gastiga maŝino kondukas al triobla pliiĝo en VirtFS-agado.
Ĉi tio, kompreneble, ne estas reto FS, sed ĝi plene reflektas la esencon de aferoj. La malavantaĝo de ĉi tiu optimumigo estas problemoj pri porteblo. Por iuj, ĉi-lasta povas esti kritika. Ekzemple, GlusterFS tute ne havas modulojn en la kerno. Dank'al ĉi tio, ĝi nun funkcias sur multaj platformoj, inkluzive de NetBSD.
Kiajn konceptojn lokaj FS-oj povus prunti de retaj kaj inverse?
Nuntempe, retaj FS-oj, kiel regulo, havas aldonaĵojn super lokaj FS-oj, do mi ne tute komprenas kiel vi povas prunti ion de ĉi-lasta. Nu, ja, ni konsideru firmaon de 4 dungitoj, en kiu ĉiu faras sian propran aferon: unu disdonas, alia sendas, la tria ricevas, la kvara vendejoj. Kaj la demando, kion la kompanio povas prunti de sia dungito, kiu konservas ĝin, sonas iel malĝusta (ĝi jam delonge havis tion, kion ĝi povus prunti de li).
Sed lokaj FS-oj havas multon por lerni de retaj. Unue, vi devus lerni de ili kiel aldoni logikajn volumojn altnivele. Nun la tn "altnivelaj" lokaj dosiersistemoj agregas logikajn volumojn ekskluzive uzante "virtuala aparato" teknologio pruntita de LVM (tiu sama infekta tavoligmalobservo kiu unue estis efektivigita en ZFS). Alivorte, tradukado de virtualaj adresoj (bloknombroj) en realajn kaj reen okazas je malalta nivelo (t.e., post kiam la dosiersistemo eligis I/O-peton).
Bonvolu noti, ke aldoni kaj forigi aparatojn al logikaj volumoj (ne speguloj) aranĝitaj sur la bloktavolo kondukas al problemoj pri kiuj provizantoj de tiaj "trajtoj" modeste silentas. Mi parolas pri fragmentiĝo ĉe realaj aparatoj, kiuj povas atingi monstrajn valorojn, dum ĉe virtuala aparato ĉio estas en ordo. Tamen malmultaj homoj interesiĝas pri virtualaj aparatoj: ĉiuj interesiĝas pri tio, kio okazas en viaj realaj aparatoj. Sed ZFS-similaj FS (same kiel ajna FS lige kun LVM) funkcias nur kun virtualaj disko-aparatoj (asignu virtualajn disko-adresojn el inter senpagaj, malfragmentu ĉi tiujn virtualajn aparatojn ktp.). Kaj ili ne havas ideon, kio okazas ĉe realaj aparatoj!
Nun imagu, ke vi havas nulan fragmentiĝon sur la virtuala aparato (tio estas, vi havas nur unu gigantan amplekson loĝanta tie), vi aldonas diskon al via logika volumo, kaj poste forigas alian hazardan diskon de via logika volumo kaj poste reekvilibrigas. Kaj tiom da fojoj. Ne estas malfacile imagi, ke sur la virtuala aparato vi ankoraŭ havos tiun saman amplekson vivanta, sed sur realaj aparatoj vi vidos nenion bonan.
La plej malbona afero estas, ke vi eĉ ne kapablas korekti ĉi tiun situacion! La nura afero, kiun vi povas fari ĉi tie, estas peti la dosiersistemon malfragmenti la virtualan aparaton. Sed ŝi diros al vi, ke ĉio estas bonega tie - estas nur unu amplekso, fragmentiĝo estas nula, kaj ĝi ne povas esti pli bona! Do, logikaj volumoj aranĝitaj ĉe la bloknivelo ne estas destinitaj por ripeta aldono/forigo de aparatoj. En bona maniero, vi nur bezonas kunmeti logikan volumon ĉe la bloknivelo unufoje, doni ĝin al la dosiersistemo, kaj poste fari nenion alian kun ĝi.
Krome, la kombinaĵo de sendependaj FS+LVM-subsistemoj ne permesas konsideri la malsaman naturon de la veturadoj de kiuj logikaj volumoj estas agregitaj. Efektive, supozu, ke vi kunvenis logikan volumon de HDD kaj solidsubstancaj aparatoj. Sed tiam la unua postulos malfragmentadon, kaj la dua ne. Por ĉi-lasta, vi devas elsendi forĵetpetojn, sed por la unuaj, ne, ktp. Tamen, en ĉi tiu kombinaĵo estas sufiĉe malfacile pruvi tian selektivecon.
Notu, ke post kreado de via propra LVM en la dosiersistemo, la situacio ne multe pliboniĝas. Krome, farante tion vi efektive ĉesigas la perspektivon iam plibonigi ĝin en la estonteco. Ĉi tio estas tre malbona. Malsamaj specoj de diskoj povas vivi sur la sama maŝino. Kaj se la dosiersistemo ne distingas inter ili, tiam kiu faros?
Alia problemo atendas la tn. Dosiersistemoj "Write-Anywhere" (ĉi tio ankaŭ inkluzivas Reiser4, se vi specifis la taŭgan transakcian modelon dum muntado). Tiaj dosiersistemoj devas disponigi malfragmentajn ilojn kiuj estas senprecedencaj en sia potenco. Kaj la malaltnivela volummanaĝero ĉi tie ne helpas, sed nur malhelpas. Fakte, kun tia administranto, via FS stokos mapon de senpagaj blokoj de nur unu aparato - virtuala. Sekve, vi povas nur malfragmenti virtualan aparaton. Ĉi tio signifas, ke via defragmentilo funkcios dum longa, longa tempo sur grandega ununura spaco de virtualaj adresoj.
Kaj se vi havas multajn uzantojn farantajn hazardajn anstataŭigojn, tiam la utila efiko de tia defragmentilo estos reduktita al nulo. Via sistemo neeviteble komencos malrapidiĝi, kaj vi nur devos faldi viajn manojn antaŭ la seniluziiga diagnozo "rompita dezajno". Pluraj defragmentiloj kurantaj sur la sama adresspaco nur malhelpos unu la alian. Estas tute alia afero se vi konservas vian propran mapon de senpagaj blokoj por ĉiu reala aparato. Ĉi tio efike paraleligos la malfragmentan procezon.
Sed ĉi tio povas esti farita nur se vi havas altnivelan logikan volumadministranton. Lokaj dosiersistemoj kun tiaj administrantoj antaŭe ne ekzistis (almenaŭ, mi ne scias pri ili). Nur retaj dosiersistemoj (ekzemple GlusterFS) havis tiajn administrantojn. Alia tre grava ekzemplo estas la utileco de kontrolo de integreco de volumo (fsck). Se vi stokas vian propran sendependan mapon de liberaj blokoj por ĉiu subvolumo, tiam la proceduro por kontroli logikan volumon povas esti efike paraleligita. Alivorte, logikaj volumoj kun altnivelaj administrantoj pli bone skalas.
Krome, kun malaltnivelaj volumadministrantoj vi ne povos organizi plenrajtajn momentfotojn. Kun LVM kaj ZFS-similaj dosiersistemoj, vi povas nur preni lokajn momentfotojn, sed ne tutmondajn momentfotojn. Lokaj momentfotoj permesas vin tuj refari nur regulajn dosieroperaciojn. Kaj neniu tie retroigos operaciojn kun logikaj volumoj (aldonante/forigante aparatojn). Ni rigardu ĉi tion kun ekzemplo. En iu momento, kiam vi havas logikan volumon de du aparatoj A kaj B enhavantaj 100 dosierojn, vi prenas momentfoton de la sistemo S kaj poste kreas pliajn cent dosierojn.
Post tio, vi aldonas aparaton C al via volumo, kaj finfine malfunkciigas vian sistemon al momentfoto S. Demando: Kiom da dosieroj kaj aparatoj enhavas via logika volumo post retroiro al S? Estos 100 dosieroj, kiel vi eble divenis, sed estos 3 aparatoj - ĉi tiuj estas la samaj aparatoj A, B kaj C, kvankam en la momento, kiam la momentfoto estis kreita, estis nur du aparatoj en la sistemo (A kaj B). ). La operacio aldona aparato C ne refunkciis, kaj se vi nun forigas aparaton C de la komputilo, ĝi koruptos viajn datumojn, do antaŭ ol forigi vi devos unue fari multekostan operacion por forigi la aparaton de la reekvilibra logika volumo, kiu disĵetos ĉiujn datumojn de aparato C al aparatoj A kaj B. Sed se via FS subtenas tutmondajn momentfotojn, tia rebalancado ne estus postulata, kaj post tuja retroiro al S, vi povus sekure forigi aparaton C de la komputilo.
Do, tutmondaj momentfotoj estas bonaj ĉar ili permesas al vi eviti la multekostan forigon (aldonon) de aparato de logika volumeno (al logika volumeno) kun granda kvanto da datumoj (kompreneble, se vi memoras "fotografi" vian sistemon). en la ĝusta tempo). Lasu min memorigi vin, ke krei momentfotojn kaj revenigi la dosiersistemon al ili estas tujaj operacioj. La demando povas ŝpruci: kiel eblas eĉ tuj retrorigi operacion sur logika volumo, kiu prenis vin tri tagojn? Sed eblas! Kondiĉe ke via dosiersistemo estas ĝuste desegnita. Mi elpensis la ideon pri tiaj "3D-fotoj" antaŭ tri jaroj, kaj pasintjare mi patentis ĉi tiun teknikon.
La sekva afero, kiun lokaj FS-oj devus lerni de retaj, estas stoki metadatumojn sur apartaj aparatoj same kiel retaj FS-oj stokas ilin sur apartaj maŝinoj (la tielnomitaj metadatumoj-serviloj). Estas aplikoj, kiuj funkcias ĉefe kun metadatenoj, kaj ĉi tiuj aplikoj povas esti tre akcelitaj metante la metadatumojn sur multekostajn alt-efikecajn stokadajn aparatojn. Kun la kombinaĵo FS+LVM, vi ne povos pruvi tian selektivecon: LVM ne scias kio estas sur la bloko, kiun vi transdonis al ĝi (datenoj tie aŭ metadatenoj).
Vi ne multe profitos de efektivigo de via propra malaltnivela LVM en la FS kompare kun la kombinaĵo FS+LVM, sed kion vi povas tre bone fari estas malordigi la FS por ke poste fariĝu neeble labori kun ĝia kodo. ZFS kaj Btrfs, kiuj rapidis kun virtualaj aparatoj, ĉiuj estas klaraj ekzemploj de kiel tavoliganta malobservo mortigas la sistemon en arkitekturaj terminoj. Do, kial mi estas ĉio ĉi? Plie, ne necesas konstrui vian propran malaltnivelan LVM en la dosiersistemo. Anstataŭe, vi devas kunigi aparatojn en logikaj volumoj je alta nivelo, kiel iuj retaj dosiersistemoj faras kun malsamaj maŝinoj (stokaj nodoj). Vere, ili faras tion abomene pro la uzo de malbonaj algoritmoj.
Ekzemploj de absolute teruraj algoritmoj estas la DHT-tradukilo en la dosiersistemo GlusterFS kaj la tielnomita CRUSH-mapo en la Ceph-dosiersistemo. Neniu el la algoritmoj, kiujn mi vidis, kontentigis min rilate simplecon kaj bona skaleblo. Do mi devis memori algebron kaj mem elpensi ĉion. En 2015, eksperimentante kun pakaĵoj super hash-funkcioj, mi elpensis kaj patentis ion, kio konvenas al mi. Nun mi povas diri, ke la provo efektivigi ĉion ĉi estis sukcesa. Mi ne vidas problemojn pri skaleblo en la nova aliro.
Jes, ĉiu subvolumo postulos apartan strukturon kiel superbloko en memoro. Ĉu tio estas tre timiga? Ĝenerale, mi ne scias, kiu "boligos la oceanon" kaj kreos logikajn volumojn de centoj da miloj aŭ pli da aparatoj sur unu loka maŝino. Se iu povas klarigi tion al mi, mi estos tre dankema. Intertempe, por mi ĉi tio estas merkata fiaĵo.
Kiel ŝanĝoj en la subsistemo de la kerno-bloka aparato (ekzemple, la aspekto de blk-mq) influis la postulojn por FS-efektivigo?
Ili havis nenian efikon. Mi ne scias, kio okazus sur la bloka tavolo, kiu necesus desegni novan FS. La interaga interfaco de ĉi tiuj subsistemoj estas tre malbona. De la ŝoforo, la FS devus esti nur tuŝita de la apero de novaj specoj de diskoj, al kiuj la bloktavolo unue estos alĝustigita, kaj poste la FS (por reiser4 tio signifos la aperon de novaj kromprogramoj).
Ĉu la apero de novaj specoj de amaskomunikilaro (ekzemple, SMR, aŭ la ĉieo de SSD-oj) signifas fundamente novajn defiojn por dosiersistemo-dezajno?
Jes. Kaj ĉi tiuj estas normalaj instigoj por la disvolviĝo de FS. Defioj povas esti malsamaj kaj tute neatenditaj. Ekzemple, mi aŭdis pri stiradoj, kie la rapideco de I/O-operacio tre dependas de la grandeco de datumo kaj ĝia kompenso. En Linukso, kie la grandeco de la FS-bloko ne povas superi la paĝan grandecon, tia disko ne montros siajn plenajn kapablojn defaŭlte. Tamen, se via dosiersistemo estas ĝuste desegnita, tiam estas ŝanco akiri multe pli el ĝi.
Kiom da homoj nuntempe laboras kun la Reiser4-kodo krom vi?
Malpli ol mi ŝatus, sed ankaŭ mi ne spertas akran mankon de rimedoj. Mi estas pli ol kontenta pri la ritmo de disvolviĝo de Reiser4. Mi ne "veturos ĉevalojn" - ĉi tio ne estas la ĝusta areo. Ĉi tie, "se vi veturas pli trankvile, vi daŭrigos!" Moderna dosiersistemo estas la plej kompleksa kerna subsistemo, kies malĝustaj projektaj decidoj povas malfari postajn jarojn da homa laboro.
Proponante volontulojn por efektivigi ion, mi ĉiam garantias, ke la klopodoj certe kondukos al la ĝusta rezulto, kiu povas esti postulata por seriozaj bezonoj. Kiel vi komprenas, ne povas esti multaj tiaj garantioj samtempe. Samtempe mi ne eltenas "ciferojn", kiuj senhonte reklamas "trajtojn" de evidente neuzebla programaro, trompantaj centojn da uzantoj kaj programistoj, kaj samtempe sidas kaj ridetas ĉe kernaj pintoj.
Ĉu iu kompanio esprimis volon subteni la disvolviĝon de Reiser4?
Jes, estis tiaj proponoj, inkl. kaj de grava vendisto. Sed por tio mi devis translokiĝi al alia lando. Bedaŭrinde, mi ne plu havas 30 jarojn, mi ne povas disiĝi kaj foriri tiel ĉe la unua fajfo.
Kiuj funkcioj nuntempe mankas de Reiser4?
Ne ekzistas "regrandigi" funkcio por simplaj volumoj, simila al tiu trovita en ReiserFS(v3). Krome, dosieroperacioj kun la flago DIRECT_IO ne damaĝus. Poste, mi ŝatus povi apartigi volumon en "semantikajn subvolumojn", kiuj ne havas fiksan grandecon, kaj kiuj povas esti muntitaj kiel sendependaj volumoj. Ĉi tiuj problemoj estas bonaj por komencantoj, kiuj volas provi sian manon pri la "reala afero".
Kaj fine, mi ŝatus havi retlogikajn volumojn kun simpla efektivigo kaj administrado (modernaj algoritmoj jam permesas tion). Sed tio, kion Reiser4 certe neniam havos, estas RAID-Z, matoraloj, liberspacaj kaŝmemoroj, 128-bitaj variabloj kaj aliaj merkataj sensencaĵoj, kiuj estiĝis sur la fono de manko de ideoj inter la programistoj de iuj dosiersistemoj.
Ĉu ĉio, kio povus esti bezonata, povas esti efektivigita per kromaĵoj?
Se ni parolas nur pri interfacoj kaj kromaĵoj (moduloj) kiuj efektivigas ilin, tiam ne ĉio. Sed se vi ankaŭ enkondukas rilatojn sur ĉi tiuj interfacoj, tiam, interalie, vi havos la konceptojn de pli altaj polimorfismoj, kun kiuj vi jam povas elteni. Imagu, ke vi hipoteze frostigis objekt-orientitan rultempan sistemon, ŝanĝis la valoron de la instrukcimontrilo por indiki alian kromprogramon, kiu efektivigas la saman X-interfacon, kaj poste malfrostigis la sistemon por ke ĝi daŭrigu ekzekuti.
Se la finuzanto ne rimarkas tian "anstataŭaĵon", tiam ni diras ke la sistemo havas nul-ordan polimorfismon en la X-interfaco (aŭ la sistemo estas heterogena en la X-interfaco, kio estas la sama afero). Se nun vi ne nur havas aron da interfacoj, sed ankaŭ havas interrilatojn sur ili (interfaca grafikaĵo), tiam vi povas enkonduki polimorfismojn de pli altaj ordoj, kiuj karakterizos la heterogenecon de la sistemo jam en la "najbareco" de iu ajn interfaco. Mi enkondukis tian klasifikon antaŭ longe, sed, bedaŭrinde, ĝi neniam okazis.
Do, helpe de kromaĵoj kaj tiaj pli altaj polimorfismoj, vi povas priskribi ajnan konatan funkcion, kaj ankaŭ "antaŭdiri" tiujn, kiuj eĉ neniam estis menciitaj. Mi ne povis strikte pruvi tion, sed ankaŭ mi ankoraŭ ne konas kontraŭekzemplon. Ĝenerale, ĉi tiu demando memorigis min pri "Erlangen Programo" de Felix Klein. Siatempe li provis reprezenti la tutan geometrion kiel branĉon de algebro (specife, grupteorio).
Nun al la ĉefa demando - kiel iras aferoj kun la promocio de Reiser4 al la ĉefa kerno? Ĉu estis publikaĵoj pri la arkitekturo de ĉi tiu dosiersistemo, pri kiuj vi parolis en la lasta intervjuo? Kiom gravas ĉi tiu demando laŭ via vidpunkto?
Ĝenerale ni de tri jaroj petas inkludon en la ĉefbranĉon. La lasta komento de Reiser en la publika fadeno kie la tirpeto estis farita restis nerespondita. Do ĉiuj pliaj demandoj ne estas por ni. Mi persone ne komprenas kial ni bezonas "kunfandiĝi" en specifan operaciumon. En Linukso, la lumo ne konverĝis kiel kojno. Do, ekzistas aparta deponejo en kiu estos pluraj branĉo-havenoj por malsamaj OS-oj. Kiu bezonas ĝin, povas kloni la respondan havenon kaj fari kion ajn vi volas per ĝi (en la permesilo, kompreneble). Nu, se iu ne bezonas ĝin, tiam ĝi ne estas mia problemo. Je ĉi tiu punkto, mi proponas konsideri la demandon pri "reklamo en la ĉefan Linuksan kernon" kiel aranĝita.
Publikaĵoj pri FS-arkitekturo estas trafaj, sed ĝis nun mi nur trovis tempon por miaj novaj rezultoj, kiujn mi konsideras pli alta prioritato. Alia afero estas, ke mi estas matematikisto, kaj en matematiko ĉiu eldonaĵo estas resumo de teoremoj kaj iliaj pruvoj. Eldoni ion ajn tie sen pruvo estas signo de malbona gusto. Se mi plene pruvos aŭ malpruvas iun deklaron pri la arkitekturo de la FS, tiam la rezulto estos tiaj amasoj, ke estos sufiĉe malfacile trapasi. Kiu bezonas ĝin? Pro tio verŝajne ĉio daŭre restas en sia malnova formo - la fontkodo kaj komentoj al ĝi.
Kio estas nova en Reiser4 dum la lastaj jaroj?
La longe atendita stabileco finfine realiĝis. Unu el la lastaj aperintaj estis cimo, kiu kondukis al "neforigeblaj" dosierujoj. La malfacilaĵo estis, ke ĝi nur aperis kontraŭ la fono de nomhash-kolizioj kaj kun certa loko de dosierujoj en arba nodo. Tamen, mi ankoraŭ ne povas rekomendi Reiser4 por produktado: por tio vi devas fari iom da laboro kun aktiva interago kun produktadsistemadministrantoj.
Ni finfine sukcesis efektivigi nian longdaŭran ideon - malsamajn transakciajn modelojn. Antaŭe, Reiser4 nur prizorgis unu malmolkoditan Macdonald-Reiser modelon. Ĉi tio kreis problemojn pri dezajno. Precipe, momentfotoj ne eblas en tia transakcia modelo - ili estos koruptitaj de atoma komponanto nomata "OVERWRITE SET". Reiser4 nuntempe subtenas tri transakciajn modelojn. En unu el ili (Write-Anywhere), la atoma komponanto OVERWRITE SET inkluzivas nur sistemajn paĝojn (bildojn de diskbitmapoj ktp.), kiuj ne povas esti "fotitaj" (la problemo de kokido kaj ovo).
Do la bildoj nun povas esti realigitaj en la plej bona ebla maniero. En alia transakcia modelo, ĉiuj modifitaj paĝoj iras nur al la OVERWRITE SET (tio estas, ĝi estas esence pura ĵurnalo). Ĉi tiu modelo estas por tiuj, kiuj plendis pri la rapida fragmentiĝo de Reiser4-diskoj. Nun en ĉi tiu modelo via sekcio fragmentiĝos ne pli rapide ol kun ReiserFS (v3). Ĉiuj tri ekzistantaj modeloj, kun kelkaj rezervoj, garantias la atomecon de operacioj, sed modeloj kun perdo de atomeco kaj konservanta nur la integrecon de la sekcio ankaŭ povas esti utilaj. Tiaj modeloj povas esti utilaj por ĉiaj aplikaĵoj (datumbazoj, ktp.), kiuj jam alprenis iujn ĉi tiujn funkciojn. Estas tre facile aldoni ĉi tiujn modelojn al Reiser4, sed mi ne faris ĝin, ĉar neniu demandis min, kaj mi persone ne bezonas ĝin.
Aperis metadatumaj kontrolsumoj kaj mi lastatempe kompletigis ilin per "ekonomiaj" speguloj" (ankoraŭ malstabila materialo). Se la kontrolsumo de iu bloko malsukcesas, Reiser4 tuj legas la respondan blokon de la kopia aparato. Notu, ke ZFS kaj Btrfs ne povas fari tion: la dezajno ne permesas ĝin. Tie vi devas ruli specialan fonan skanadon nomitan "scrub" kaj atendi, ke ĝi atingos la probleman blokon. Programistoj figure nomas tiajn eventojn "lambastonoj".
Kaj fine aperis heterogenaj logikaj volumoj, proponante ĉion, kion ZFS, Btrfs, bloktavolo, kaj ankaŭ FS+LVM-kombinaĵoj principe ne povas provizi - paralela skalo, O(1) disk-adresa alsignilo, travidebla datummigrado inter subvolumoj. Ĉi-lasta ankaŭ havas uzantinterfacon. Nun vi povas facile movi la plej varmajn datumojn al la plej alt-efikeca stirado de via volumo.
Krome, eblas urĝe forĵeti ajnajn malpurajn paĝojn al tia disko, tiel signife akcelante aplikaĵojn, kiuj ofte nomas fsync(2). Mi rimarkas, ke la bloktavola funkcio, nomata bcache, tute ne provizas tian agadliberecon. Novaj logikaj volumoj baziĝas sur miaj algoritmoj (estas respondaj patentoj). La programaro jam estas sufiĉe stabila, estas sufiĉe eble provi ĝin, mezuri rendimenton, ktp. La sola ĝeno estas, ke nuntempe vi devas permane ĝisdatigi la voluman agordon kaj stoki ĝin ie.
Ĝis nun mi povis efektivigi miajn ideojn je 10 procentoj.Tamen mi sukcesis pri tio, kion mi konsideris la plej malfacila afero - kunligi logikajn volumojn kun fulmproceduro, kiu plenumas ĉiujn prokrastitajn agojn en reiser4. Ĉio ĉi estas ankoraŭ en la eksperimenta branĉo "formato41".
Ĉu Reiser4 pasas xfstests?
Almenaŭ ĝi faris por mi kiam mi preparis la lastan eldonon.
Ĉu principe eblas fari Reiser4 reto (areto) FS uzante kromaĵojn?
Ĝi eblas, kaj eĉ necesa! Se vi kreas retan dosieron bazitan sur taŭge desegnita loka dosiersistemo, la rezulto estos tre impona! En modernaj retaj FS-oj, mi ne kontentas pri la ĉeesto de backend-stoka nivelo, kiu estas efektivigita uzante ajnan lokan FS. La ekzisto de ĉi tiu nivelo estas tute nepravigebla. La reto FS devas rekte interagi kun la bloktavolo, kaj ne peti la lokan FS krei iujn ajn aliajn servajn dosierojn!
Ĝenerale, dividado de dosiersistemoj en loka kaj reto estas de la malbonulo. Ĝi estiĝis el la neperfekteco de la algoritmoj, kiuj estis uzitaj antaŭ tridek jaroj, kaj anstataŭ kiuj ankoraŭ nenio estis proponita. Ĉi tio ankaŭ estas la kialo de apero de amaso da nenecesaj programaj komponantoj (diversaj servoj, ktp.). En bona maniero, devus ekzisti nur unu FS en la formo de kernomodulo kaj aro da uzantutiloj instalitaj sur ĉiu maŝino - cluster nodo. Ĉi tiu FS estas kaj loka kaj reto. Kaj nenio pli!
Se nenio funkcias kun Reiser4 en Linukso, mi ŝatus proponi FS por FreeBSD (citaĵo el antaŭa intervjuo: “...FreeBSD... havas akademiajn radikojn... Kaj tio signifas, ke kun alta grado de probableco ni trovos komunan lingvon kun la programistoj”) ?
Do, kiel ni ĵus eksciis, ĉio jam perfekte funkciis kun Linukso: ekzistas aparta funkcianta pordo Reiser4 por ĝi en la formo de majstra branĉo de nia deponejo. Mi ne forgesis pri FreeBSD! Oferto! Mi estas preta labori proksime kun tiuj, kiuj bone konas la internojn de FreeBSD. Cetere: kion mi tre ŝatas pri ilia komunumo estas ke tie decidoj estas faritaj de ĝisdatigita konsilio de sendependaj fakuloj, kiu havas nenion komunan kun la registara trompo de unu konstanta persono.
Kiel vi taksas la Linuksan uzantkomunumon hodiaŭ? Ĉu ĝi fariĝis pli "pop"?
Konsiderante la naturon de mia laboro, estas sufiĉe malfacile por mi taksi tion. Plejparte uzantoj venas al mi kun cimraportoj kaj petoj ripari la sekcion. Uzantoj kiel uzantoj. Iuj estas pli lertaj, iuj malpli. Ĉiuj estas traktataj same. Nu, se la uzanto ignoras miajn instrukciojn, do pardonu min: la ignora ordo estos enmetita ankaŭ miaflanke.
Ĉu eblas antaŭdiri la evoluon de dosiersistemoj por la venontaj kvin ĝis dek jaroj? Kiujn vi opinias, ke estas la ĉefaj defioj, kiujn FS-programistoj povas renkonti?
Jes, ne estas malfacile fari tian prognozon. Delonge ne ekzistas disvolviĝo de dosiersistemoj en la kontraŭfluo. Nur la aspekto de tia estas kreita. Programistoj de lokaj dosiersistemoj renkontis problemojn asociitajn kun malbona dezajno. Ĉi tie necesas averto. Mi ne konsideras la tiel nomatan "stokado", "lekado" kaj portado de kodo kiel evoluo kaj evoluo. Kaj mi ne klasifikas la miskomprenon nomatan "Btrfs" kiel evoluon pro la kialoj, kiujn mi jam klarigis.
Ĉiu diakilo nur plimalbonigas siajn problemojn. Nu. kaj ĉiam estas diversaj specoj de "evangelistoj" por kiuj "ĉio funkcias". Esence, ĉi tiuj estas lernejinfanoj kaj studentoj preterlasantaj prelegojn. Nur imagu: ĝi funkcias por li, sed la profesoro ne. Kia adrenalino estas ĉi tio! Laŭ mia vidpunkto, la plej granda damaĝo estas kaŭzita de la "metiistoj", kiuj rapidis por entuziasme "ŝraŭbi" la mirindajn trajtojn de Btrfs sur ĉiajn tavolojn kiel systemd, docker, ktp. - tio jam similas al metastazoj.
Ni provu nun fari prognozon por kvin ĝis dek jaroj. Mi jam mallonge listigis, kion ni faros en Reiser4. La ĉefa defio por lokaj FS-programistoj de kontraŭflue estos (jes, ĝi jam fariĝis) la malkapablo fari decan laboron por salajro. Sen ajnaj ideoj en la kampo de datumstokado, ili daŭre provos fliki ĉi tiujn malfeliĉajn VFS, XFS kaj ext4. La situacio kun VFS aspektas precipe komika sur ĉi tiu fono, rememoriga pri la freneza modernigo de restoracio en kiu ne estas kuiristoj, kaj neniuj kuiristoj estas atenditaj.
Nun la VFS-kodo, sen iuj kondiĉoj, ŝlosas plurajn memorpaĝojn samtempe kaj invitas la suban FS funkcii sur ili. Ĉi tio estis enkondukita por plibonigi la agadon de Ext4 pri forigo-operacioj, sed kiel estas facile kompreni, tia samtempa ŝlosado estas tute nekongrua kun altnivelaj transakciaj modeloj. Tio estas, vi ne povos simple aldoni subtenon por iu inteligenta dosiersistemo en la kerno. Mi ne scias, kia estas la situacio en aliaj areoj de Linukso, sed koncerne dosiersistemojn, ajna evoluo ĉi tie verŝajne ne kongruos kun la politiko plenumita de Torvalds praktike (akademiaj projektoj estas forĵetitaj, kaj skamantoj, kiuj ne havas ideon, kia B-arbo, senfinaj kreditoj de fido estas eldonitaj). Tial, kurso estis fiksita por malrapida kadukiĝo. Kompreneble, ili provos per sia tuta forto pasigi ĝin kiel "evoluo".
Plue, la "gardantoj" de dosiersistemoj, konsciante, ke vi ne povas multe gajni el "stokado" sole, provos sian manon pri pli enspeziga komerco. Ĉi tiuj estas, kiel regulo, distribuitaj dosiersistemoj kaj virtualigo. Eble ili portos la modan ZFS aliloken, kie ĝi ankoraŭ ne ekzistas. Sed ĝi, kiel ĉiuj FS de la kontraŭfluo, similas novjaran arbon: se vi povas pendigi aliajn malgrandajn aferojn supre, tiam vi ne povas profundiĝi. Mi konfesas, ke eblas konstrui seriozan entreprenan sistemon bazitan sur ZFS, sed ĉar ni nun diskutas pri la estonteco, mi povas nur bedaŭrinde konstati, ke ZFS ĉi-rilate estas senespera: per siaj virtualaj aparatoj la uloj fortranĉis la oksigenon. por si mem kaj estontaj generacioj por plua evoluo. ZFS estas afero de la pasinteco. Kaj ext4 kaj XFS eĉ ne estas antaŭhieraŭ.
Menciindas aparte pri la sensacia koncepto de "Linuksa dosiersistemo de venonta generacio". Ĉi tio estas tute politika kaj merkatika projekto kreita por la ŝanco, por tiel diri, "alpingli la estontecon de dosiersistemoj" en Linukso malantaŭ specifaj signoj. La fakto estas, ke Linukso kutimis esti "nur por amuzo". Sed nun ĝi estas ĉefe monfaranta maŝino. Ili estas faritaj sur ĉio ebla. Ekzemple, estas tre malfacile krei bonan programaron, sed inteligentaj "programistoj" delonge rimarkis, ke tute ne necesas streĉi: vi povas sukcese vendi neekzistantan programaron, kiu estis anoncita kaj reklamita ĉe ĉia publiko. eventoj - la ĉefa afero estas, ke la prezentaj diapozitivoj enhavu pli da "trajtoj".
Dosiersistemoj estas perfektaj por tio, ĉar vi povas sekure marĉandi dum dek jaroj pri la rezulto. Nu, se iu poste plendas pri la manko de ĉi tiu sama rezulto, tiam li simple nenion komprenas pri dosiersistemoj! Ĉi tio memorigas pri financa piramido: ĉe la supro troviĝas la aventuristoj, kiuj komencis ĉi tiun malordon, kaj tiuj malmultaj, kiuj estis "bonŝancaj": ili "retiris dividendojn", t.e. ricevis monon por disvolviĝo, ricevis bone pagitan laboron kiel administrantoj, "montris" ĉe konferencoj, ktp.
Poste venos tiuj, kiuj estas "malbonŝancaj": ili kalkulos perdojn, traktos la sekvojn de deplojado de neuzebla programaro en produktadon, "ktp. Estas multaj pli da ili. Nu, ĉe la bazo de la piramido estas grandega amaso da programistoj "segantaj" senutilan kodon. Ili estas la plej grandaj perdantoj, ĉar malŝparita tempo ne povas esti redonita. Tiaj piramidoj estas ege utilaj al Torvalds kaj liaj kunuloj. Kaj ju pli da ĉi tiuj piramidoj, des pli bone por ili. Por nutri tiajn piramidojn, io ajn povas esti prenita en la kernon. Kompreneble, publike oni diras la malon. Sed mi juĝas ne per vortoj sed per agoj.
Do, "la estonteco de dosiersistemoj en Linukso" estas ankoraŭ alia tre reklamita, sed apenaŭ uzebla programaro. Post Btrfs, kun alta probableco, la loko de tia "estonteco" estos prenita de Bcachefs, kio estas alia provo transiri la Linuksan bloktavolon kun dosiersistemo (malbona ekzemplo estas kontaĝa). Kaj kio estas tipa: estas la samaj problemoj kiel en Btrfs. Mi suspektis tion dum longa tempo, kaj tiam iel mi ne povis rezisti kaj rigardis en la kodon - ĝi estas vera!
La aŭtoroj de Bcachefs kaj Btrfs, kreante sian FS, aktive uzis aliulajn fontojn, komprenante malmulte pri ili. La situacio tre memorigas pri la infanludo "rompita telefono". Kaj mi povas proksimume imagi kiel ĉi tiu kodo estos inkluzivita en la kerno. Efektive, neniu vidos la "rastilojn" (ĉiu surpaŝos ilin poste). Post multaj kvereloj pri la stilo de la kodo, akuzoj pri neekzistantaj malobservoj ktp., konkludo estos farita pri la "lojaleco" de la aŭtoro, kiom bone li "interagas" kun aliaj programistoj, kaj kiom sukcese ĉio ĉi povas. poste estu venditaj al korporacioj.
La fina rezulto neniun interesos. Antaŭ dudek jaroj, eble, mi interesiĝus, sed nun la demandoj estas starigitaj alimaniere: ĉu eblos antaŭenigi tion, por ke iuj homoj estos dungitaj ene de la venontaj dek jaroj. Kaj, ve, ne kutimas demandi pri la fina rezulto.
Ĝenerale, mi forte konsilus kontraŭ komenci reinventi vian dosiersistemon de nulo. Ĉar eĉ signifaj financaj investoj ne sufiĉos por akiri ion konkurencivan en dek jaroj. Kompreneble, mi parolas pri seriozaj projektoj, kaj ne pri tiuj, kiujn oni intencas "puŝi" en la kernon. Do, pli efika maniero esprimi vin estas aliĝi al realaj evoluoj, kiel ni. Ĉi tio kompreneble ne estas facila por fari - sed tia estas la kazo kun ajna altnivela projekto.
Unue, vi devos sendepende venki la problemon, kiun mi proponos. Post tio, konvinkite pri la seriozeco de viaj intencoj, mi komencos helpi. Tradicie, ni uzas nur niajn proprajn evoluojn. La esceptoj estas kunpremaj algoritmoj kaj kelkaj haŝfunkcioj. Ni ne sendas programistojn vojaĝi al konferencoj, kaj tiam ni ne sidas kaj kombinas la ideojn de aliaj homoj ("eble kio okazos"), kiel kutimas en la plej multaj noventreprenoj.
Ni mem disvolvas ĉiujn algoritmojn. Mi estas nuntempe interesita pri la algebraj kaj kombinecaj aspektoj de datumstokado-scienco. Aparte, finhavaj kampoj, asimptotikoj, pruvo de neegalaĵoj. Ankaŭ estas laboro por ordinaraj programistoj, sed mi devas tuj averti vin: ĉiuj sugestoj por "rigardi alian FS kaj fari la samon" estas ignorataj. Flikaĵoj celantaj pli proksiman integriĝon kun Linukso per VFS ankaŭ iros tien.
Do, ni ne havas rastilon, sed ni komprenas, kien ni devas movi, kaj ni certas, ke ĉi tiu direkto estas la ĝusta. Ĉi tiu kompreno ne venis en formo de manao el la ĉielo. Mi rememorigu vin, ke ni havas 29 jarojn da disvolva sperto malantaŭ ni, du dosiersistemojn skribitajn de nulo. Kaj la sama nombro da datumoj reakiro utilecoj. Kaj ĉi tio estas multe!
fonto: opennet.ru