Toinen haastattelu Eduard Shishkinin, Reiser4-tiedostojärjestelmän kehittäjän kanssa, on julkaistu.
Muistuta aluksi lukijoita missä ja kenelle työskentelet.
Työskentelen päävarastoarkkitehtina Huawei Technologiesissa, Saksan tutkimuskeskuksessa. Virtualisointiosastolla käsittelen tiedon varastoinnin eri puolia. Toimintani ei liity tiettyyn käyttöjärjestelmään.
Oletko tällä hetkellä sitoutunut pääytimen haaraan?
Hyvin harvoin ja vain jos työnantajani niin vaatii. Viimeksi noin kolme vuotta sitten lähetin korjaustiedostoja lisätäkseni isäntien tallennuskapasiteettia 9p-protokollalla (toinen nimi tälle yritykselle on VirtFS). Tässä on tehtävä yksi tärkeä huomautus: vaikka olen työskennellyt Linuxin kanssa pitkään, en ole koskaan ollut sen fani, eli "hengitän tasaisesti", kuten kaikessa muussakin. Erityisesti, jos huomaan virheen, voin huomauttaa siitä korkeintaan kerran. Ja jotta voit sitten seurata jotakuta ja suostutella hänet - tätä ei tapahdu.
Muistan viime kerralla, kymmenen vuotta sitten, kun olit melko kriittinen ytimen kehitystyyliä kohtaan. Onko mikään muuttunut sinun (tai kenties yrityksen) näkökulmasta, onko yhteisöstä tullut herkempi vai ei? Jos ei, kenen luulet olevan syyllinen?
En nähnyt mitään muutosta parempaan. Yhteisön pääongelma on tieteen korvaaminen poliittisilla tekniikoilla, henkilökohtaisilla suhteilla, enemmistön mielipiteillä, populismilla, "sisäisten äänien" neuvoilla, mätäillä kompromissilla, kaikella muulla kuin tieteellä. Tietojenkäsittelytiede, sanotaanpa mitä tahansa, on ennen kaikkea eksaktia tiedettä. Ja jos joku alkaa julistaa omaa arvoaan 2x2:lle, joka on eri kuin 4, "Linux way" -lipun alla tai jonkin muun lipun alla, siitä ei todennäköisesti ole mitään muuta kuin haittaa.
Kaikki ongelmat johtuvat ensisijaisesti päätöksentekijöiden epäpätevyydestä ja koulutuksen puutteesta. Jos johtaja on epäpätevä, hän ei pysty tekemään objektiivista, riittävää päätöstä. Jos hän on myös sivistymätön, hän ei löydä pätevää asiantuntijaa, joka antaisi hänelle oikeat neuvot. Suurella todennäköisyydellä valinta osuu huijariin, joka sanoo "näennäisesti oikeita asioita". Epäpätevien yksinäisten johtajien ympärille kehittyy aina korruptoitunut ympäristö. Lisäksi historia ei tunne poikkeuksia tässä suhteessa, ja yhteisö on tämän selkein vahvistus.
Miten arvioit Btrfs-kehityksen edistymistä? Päästiko tämä FS eroon lastensairauksista? Miten asennat sen itsellesi - FS:ksi "kotiin" vai myös yrityskäyttöön?
En päässyt siitä eroon. Kaikki, mitä mainitsin 11 vuotta sitten, on edelleen ajankohtainen. Yksi Btrfs:n ongelmista, joka tekee siitä sopimattoman vakaviin tarpeisiin, on vapaan tilan ongelma. En edes puhu siitä, että käyttäjää pyydetään juoksemaan kauppaan hakemaan uutta levyä tilanteissa, joissa mikä tahansa muu FS näyttäisi osiolla paljon vapaata tilaa. Kyvyttömyys suorittaa operaatiota loogisella tilavuudella vapaan tilan puutteen vuoksi ei myöskään ole pahin asia. Pahinta on, että etuoikeutettu käyttäjä voi melkein aina ohittaa kaikki levykiintiöt ja riistää kaikilta vapaan tilan melko lyhyessä ajassa.
Se näyttää tältä (testattu Linux-ytimelle 5.12). Juuri asennetussa järjestelmässä käynnistetään skripti, joka silmukassa luo tietynnimiset tiedostot kotihakemistoon, kirjoittaa niihin dataa tietyin poikkeuksin ja sitten poistaa nämä tiedostot. Minuutin tämän skriptin suorittamisen jälkeen ei tapahdu mitään epätavallista. Viiden minuutin kuluttua osion varatun tilan osuus kasvaa hieman. Kahden tai kolmen tunnin kuluttua se saavuttaa 50 % (alkuarvolla 15 %). Ja viiden tai kuuden tunnin työskentelyn jälkeen komentosarja kaatuu virheellä "osiossa ei ole vapaata tilaa". Tämän jälkeen et voi enää kirjoittaa edes 4K-tiedostoa osioon.
Mielenkiintoinen tilanne syntyy: et kirjoittanut mitään osioon, ja kaikki vapaa tila (noin 85%) katosi jonnekin. Tällaisen hyökkäyksen kohteena olevan osan analysointi paljastaa monia puusolmuja, jotka sisältävät vain yhden kohteen (avaimella varustettu objekti), joiden koko on useita tavuja. Toisin sanoen sisältö, joka aiemmin vei 15% levytilasta, osoittautui tasaisesti "takeroituneeksi" koko osion yli, joten uutta tiedostoa ei ole minnekään kirjoittaa, koska sen avain on suurempi kuin kaikki olemassa olevat, ja vapaa osion lohkot ovat loppuneet.
Lisäksi tämä kaikki tapahtuu jo Btrfs-peruskokoonpanossa (ilman tilannekuvia, alilevyjä jne.), eikä sillä ole väliä, kuinka päätät tallentaa tiedostokappaleet kyseiseen FS:ään ("fragmentteina" puussa tai laajuuksina muotoilemattomista lohkoista) - lopputulos on sama.
Et voi altistaa muita ylävirran tiedostojärjestelmiä tällaiselle hyökkäykselle (riippumatta siitä, mitä he kertovat sinulle). Selitin ongelman syyn kauan sitten: tämä on Btrfs:n B-puukonseptin täydellinen perversio, joka mahdollistaa sen spontaanin tai tarkoituksellisen rappeutumisen. Erityisesti tietyillä kuormituksilla tiedostojärjestelmäsi "hajoaa" jatkuvasti itsestään käytön aikana ilman ulkopuolista apua. On selvää, että kaikenlaiset "painattavat" taustaprosessit pelastavat päivän vain yksittäisillä työasemilla.
Kollektiivisilla palvelimilla hyökkääjä voi aina "päästää edellään". Järjestelmänvalvoja ei edes pysty määrittämään, kuka häntä tarkalleen kiusaa. Nopein tapa korjata tämä ongelma Btrfsissä on palauttaa tavallisen B-puun rakenne, ts. levymuodon uudelleensuunnittelu ja merkittävien Btrfs-koodin osien uudelleenkirjoittaminen. Tämä kestää 8–10 vuotta, mukaan lukien virheenkorjaus, edellyttäen, että kehittäjät noudattavat tiukasti alkuperäisiä artikkeleita asiaankuuluvista algoritmeista ja tietorakenteista eivätkä pelanneet "rikkinäisen puhelimen" -peliä, kuten "Linuxissa" on tapana (ja kannustetaan) tapa".
Tässä meidän on myös lisättävä aika, jonka kehittäjät tarvitsevat ymmärtääkseen kaiken tämän. Tässä se vaikeutuu. Joka tapauksessa 10 vuotta ei riittänyt heille ymmärtämään. No, siihen asti ei voi toivoa ihmettä. Se ei tapahdu asennusvaihtoehdon muodossa, "josta sinä ja minä emme tienneet", tai korjaustiedoston muodossa, jonka valmistelu on "vain liiketoimintakysymys". Jokaiselle tällaiselle kiireelliselle "korjaukselle" esitän uuden rappeutumisskenaarion. B-puut ovat yksi suosikkiaiheistani, ja täytyy sanoa, että nämä rakenteet eivät siedä vapauksia itsensä kanssa!
Kuinka sijoitan Btrf:t itselleni? Asiana, jota ei ehdottomasti voida kutsua tiedostojärjestelmäksi, saati sitten käytetyksi. Koska määritelmän mukaan FS on käyttöjärjestelmän alijärjestelmä, joka vastaa "levytilan" resurssin tehokkaasta hallinnasta, mitä emme näe Btrfs:n tapauksessa. Kuvittele, että tulit kauppaan ostamaan kelloa, jotta et myöhästy töistä, ja kellon sijaan he myivät sinulle sähkögrillin ajastimella enintään 30 minuutiksi. Joten tilanne Btrfs:n kanssa on vielä pahempi.
Postituslistoja selailemalla törmään usein väitteeseen, että levytilan tehokas hallinta ei ole enää relevanttia asemien halpojen vuoksi. Tämä on täyttä hölynpölyä. Ilman tehokasta levytilan hallintaa käyttöjärjestelmästä tulee haavoittuva ja käyttökelvoton. Riippumatta koneen levyjen kapasiteetista.
Haluaisin pyytää kommenttia Btrfs-tuen lopettamisesta RHEL:ssä.
Tässä ei ole mitään erityistä kommentoitavaa, kaikki on hyvin selvää. Heillä oli myös se "teknologian esikatseluna". Joten en käynyt läpi tätä "esikatselua". Älä anna tämän etiketin roikkua ikuisesti! Mutta he eivät voi julkaista virheellistä sivusuunnittelutuotetta täydellä tuella. RHEL on yritys, eli määrätyt hyödyke-raha-suhteet. Red Hat ei voi kiusata käyttäjiä kuten he tekevät Btrfs-postituslistalla. Kuvittele tilanne: asiakas, joka maksoi kovalla työllä ansaitsemansa rahansa levystä ja myös sinulle tuesta, haluaa ymmärtää, mihin hänen levytilansa katosi, kun hän ei kirjoittanut mitään. Mitä aiot vastata hänelle tähän?
Edelleen. Red Hatin asiakkaita ovat tunnetut suuret pankit ja pörssit. Kuvittele, mitä tapahtuisi, jos ne joutuisivat DoS-hyökkäyksiin mainitun Btrfs-haavoittuvuuden perusteella. Kenen luulet olevan vastuussa tästä? Niille, jotka aikovat osoittaa sormellaan GPL-lisenssin riviä, jossa on kirjoitettu, että kirjoittaja ei ole vastuussa mistään, sanon heti: "piilota se pois!" Red Hat vastaa, ja sillä tavalla, että se ei tunnu riittävän! Mutta tiedän, että Red Hatilla ei ole tämänkaltaisia ongelmia, kun otetaan huomioon heidän erityisen vahva QA-insinööritiimi, jonka kanssa minulla oli aikanaan mahdollisuus tehdä tiivistä yhteistyötä.
Miksi jotkut yritykset jatkavat Btrfs:n tukemista yritystuotteissaan?
Huomaa, että tuotteen nimessä oleva etuliite "yritys" ei merkitse paljon. Yritys on vastuun mitta, joka on sisällytetty sopimussuhteeseen asiakkaan kanssa. Tiedän vain yhden GNU/Linux-pohjaisen yrityksen - RHEL. Kaikki muu on minun näkökulmastani vain esitetty yrityksenä, mutta se ei ole sitä. Ja lopuksi, jos jollekin on kysyntää, niin tarjontaa on aina (meidän tapauksessamme tämä on mainittu "tuki"). Kysyntää on aivan kaikelle, mm. ja käyttökelvottomia ohjelmistoja. Se, miten tällainen kysyntä muodostuu ja kuka sitä ruokkii, on toinen aihe.
Joten en tekisi hätiköityjä johtopäätöksiä sen jälkeen, kun Facebookin huhutaan ottaneen käyttöön Btrfs:n palvelimilleen. Lisäksi suosittelen pitämään näiden palvelimien osoitteet huolellisesti salassa yllä mainituista syistä.
Miksi XFS-koodin puhdistamiseen on viime aikoina tehty niin paljon vaivaa? Loppujen lopuksi tämä on alun perin kolmannen osapuolen tiedostojärjestelmä, ja ext4 on ollut vakaa pitkään ja sillä on jatkuvuus aiemmista yhtä vakaista versioista. Mitä kiinnostusta Red Hatilla on XFS:ää kohtaan? Onko järkevää kehittää aktiivisesti kahta tarkoitukseltaan samanlaista tiedostojärjestelmää - ext4 ja XFS?
En muista mikä tämän motiivina oli. On täysin mahdollista, että aloite tuli Red Hatin asiakkailta. Muistan, että tällaista tutkimusta tehtiin: joissakin ylävirran tiedostojärjestelmissä luotiin valtava määrä objekteja uuden sukupolven huippuluokan asemille. Tulosten mukaan XFS käyttäytyi paremmin kuin ext4. Joten he alkoivat mainostaa sitä lupaavimpana. Joka tapauksessa en etsiisi täältä mitään sensaatiomaista.
Minulle se on kuin he olisivat korvanneet naskalin saippualla. Ei ole mitään järkeä kehittää ext4:ää ja XFS:ää. Sekä rinnakkain että mistä tahansa niistä valita. Tästä ei tule mitään hyvää. Vaikka luonnossa on usein tilanteita, jolloin kasvupotentiaalia on paljon, mutta kasvua ei ole. Tällöin syntyy erilaisia omituisen rumia kasvaimia, joihin jokainen osoittaa sormella ("Oi, katso, mitä et näe tässä elämässä!").
Luuletko, että kerrosrikkomus on ratkaistu (kielteisessä mielessä) salaustoimintojen myötä ext4:ssä, F2FS:ssä (puhumattakaan Btrfs:n RAIDista)?
Yleensä kaikkien tasojen käyttöönotto ja niiden rikkomattomuudesta päättäminen on yleensä politiikkaa, enkä ryhdy kommentoimaan täällä mitään. Tason rikkomisen objektiiviset näkökohdat eivät kiinnosta ketään, mutta voimme harkita joitain niistä käyttämällä esimerkkiä rikkomisesta "ylhäältä" eli lohkokerroksessa jo olemassa olevan toiminnallisuuden toteutusta FS:ssä. Tällainen "rikkomus" on perusteltua vain harvoja poikkeuksia lukuun ottamatta. Jokaisessa tällaisessa tapauksessa sinun on ensin todistettava kaksi asiaa: että sitä todella tarvitaan ja että järjestelmän suunnittelu ei vahingoita sitä.
Esimerkiksi peilaus, joka on perinteisesti ollut lohkokerroksen toiminta, on järkevää toteuttaa tiedostojärjestelmätasolla. Eri syistä. Esimerkiksi "hiljaista" tietojen korruptiota (bittimätä) esiintyy levyasemissa. Tällöin laite toimii oikein, mutta lohkodata vaurioituu yllättäen kaukaisen kvasaarin lähettämän kovan gamma-kvantin vaikutuksesta jne. Pahinta on, jos tämä lohko osoittautuu FS-järjestelmälohkoksi (superlohko, bittikarttalohko, tallennuspuusolmu jne.), koska tämä johtaa varmasti ytimen paniikkiin.
Huomaa, että lohkokerroksen (ns. RAID 1) tarjoamat peilit eivät pelasta sinua tästä ongelmasta. No, todellakin: pitäisikö jonkun tarkistaa tarkistussummat ja lukea replika epäonnistumisen varalta? Lisäksi on järkevää peilata ei vain kaikkea, vaan vain metatiedot. Jotkut tärkeät tiedot (esimerkiksi kriittisten sovellusten suoritettavat tiedostot) voidaan tallentaa metatietoina. Tässä tapauksessa he saavat samat turvallisuustakuut. On järkevää uskoa jäljellä olevien tietojen suojaaminen muille alajärjestelmille (ehkä jopa käyttäjäsovelluksille) - olemme tarjonneet tähän kaikki tarvittavat ehdot.
Tällaisilla "taloudellisilla" peileillä on oikeus olemassaoloon, ja ne voidaan järjestää tehokkaasti vain tiedostojärjestelmätasolla. Muuten tasoitusrikkomus sotkee alijärjestelmää monistetulla koodilla joidenkin mikroskooppisten etujen vuoksi. Silmiinpistävä esimerkki tästä on RAID-5:n toteutus FS:n avulla. Tällaiset ratkaisut (oma RAID / LVM tiedostojärjestelmässä) tuhoavat jälkimmäisen arkkitehtonisesti. Tässä on myös huomioitava, että erityyppiset markkinointihuijarit "laittavat virralle" kerrosrikkomuksia. Ideoiden puuttuessa alijärjestelmiin lisätään toiminnallisuutta, jota on jo pitkään toteutettu viereisillä tasoilla, tämä esitetään uutena erittäin hyödyllisenä ominaisuutena ja sitä viedään aktiivisesti eteenpäin.
Reiser4:ää syytettiin tasojen rikkomisesta "alhaalta". Perustuen siihen, että tiedostojärjestelmä ei ole monoliittinen, kuten kaikki muut, vaan modulaarinen, tehtiin perusteeton oletus, että se tekee sen, mitä ylätason (VFS) pitäisi tehdä.
Onko mahdollista puhua ReiserFS v3.6:n ja esimerkiksi JFS:n kuolemasta? Viime aikoina he eivät ole saaneet juuri lainkaan huomiota ytimessä. Ovatko ne vanhentuneita?
Tässä meidän on määriteltävä, mitä ohjelmistotuotteen kuolema tarkoittaa. Toisaalta niitä käytetään menestyksekkäästi (sitä varten ne loppujen lopuksi luotiin), mikä tarkoittaa, että he elävät. Toisaalta en voi puhua JFS:n puolesta (en tiedä paljoa), mutta ReiserFS (v3) on erittäin vaikea mukautua uusiin trendeihin (käytännössä testattu). Tämä tarkoittaa, että tulevaisuudessa kehittäjät eivät kiinnitä huomiota siihen, vaan niihin, jotka on helpompi mukauttaa. Tältä puolelta käy ilmi, että se on valitettavasti kuollut arkkitehtonisesti. En manipuloisi "moraalisesti vanhentuneen" käsitettä ollenkaan. Se sopii hyvin esimerkiksi vaatekaappiin, mutta ei ohjelmistotuotteisiin. Jossakin on käsitys alemmuudesta ja paremmuudesta. Voin ehdottomasti sanoa, että ReserFS v3 on nyt huonompi kuin Reiser4 kaikessa, mutta joissain työkuormissa se on parempi kuin kaikki muut ylävirran FS:t.
Tiedätkö FS Tux3:n ja HAMMER/HAMMER2:n (FS for DragonFly BSD) kehityksestä?
Kyllä, tiedämme. Tux3:ssa olin kerran kiinnostunut heidän tilannekuvien (ns. "versioosoittimien") tekniikasta, mutta Reiser4:ssä mennään todennäköisesti eri reittiä. Olen pitkään ajatellut snapshot-kuvien tukemista, enkä ole vielä päättänyt, kuinka ne toteutan yksinkertaisissa Reiser4-taltioissa. Tosiasia on, että Ohad Rodehin ehdottama uusi "laiska" referenssilaskuritekniikka toimii vain B-puille. Meillä ei ole niitä. Niille tietorakenteille, joita käytetään Reiesr4:ssä, "laiskoja" laskureita ei ole määritelty - niiden käyttöönottamiseksi on tarpeen ratkaista tietyt algoritmiset ongelmat, joita kukaan ei ole vielä ottanut.
HAMMERin mukaan: Luin artikkelin tekijältä. Ei kiinnosta. Jälleen B-puut. Tämä tietorakenne on toivottoman vanhentunut. Hylkäsimme sen viime vuosisadalla.
Miten arvioit CephFS/GlusterFS/etc:n kaltaisten verkkoklusterien kasvavaa kysyntää? Tarkoittaako tämä vaatimus kehittäjien prioriteettien siirtymistä kohti verkko FS:ää ja riittämätöntä huomiota paikalliseen FS:ään?
Kyllä, tällainen prioriteettien muutos on tapahtunut. Paikallisten tiedostojärjestelmien kehitys on pysähtynyt. Valitettavasti paikallisten volyymien merkittävän tekeminen on nyt melko vaikeaa, eivätkä kaikki pysty siihen. Kukaan ei halua panostaa niiden kehittämiseen. Tämä on suunnilleen sama kuin pyytää kaupallista organisaatiota myöntämään rahaa matemaattiseen tutkimukseen - ilman innostusta he kysyvät, kuinka voit ansaita rahaa uudella lauseella. Nyt paikallinen FS on jotain, joka taianomaisesti ilmestyy "pakkauksesta" ja "pitäisi aina toimia", ja jos se ei toimi, se aiheuttaa osoittelematonta murinaa, kuten: "Kyllä, mitä he ajattelevat!"
Tästä johtuu huomion puute paikalliseen FS:ään, vaikka sillä alueella on vielä paljon työtä. Ja kyllä, kaikki ovat siirtyneet hajautettuun tallennustilaan, joka on rakennettu jo olemassa olevien paikallisten tiedostojärjestelmien pohjalta. Se on nyt erittäin muotia. Ilmaisu "Big Data" aiheuttaa monille adrenaliinin, ja se yhdistetään konferensseihin, työpajoihin, suuriin palkoihin jne.
Kuinka järkevää on periaatteessa toteuttaa verkkotiedostojärjestelmä ydintilaan käyttäjäavaruuden sijaan?
Erittäin järkevä lähestymistapa, jota ei ole vielä otettu käyttöön missään. Yleisesti kysymys siitä, missä tilassa verkkotiedostojärjestelmä tulisi toteuttaa, on "kaksiteräinen miekka". No, katsotaanpa esimerkkiä. Asiakas tallensi tiedot etäkoneelle. Ne putosivat hänen sivun välimuistiin likaisten sivujen muodossa. Tämä on tehtävä "ohualle yhdyskäytävälle" olevalle verkkotiedostojärjestelmälle ydintilassa. Sitten käyttöjärjestelmä ennemmin tai myöhemmin pyytää sinua kirjoittamaan nämä sivut levylle vapauttaaksesi ne. Sitten IO-välitys (lähettävä) verkon FS-moduuli tulee peliin. Se määrittää, mihin palvelinkoneeseen (palvelinsolmuun) nämä sivut siirtyvät.
Sitten verkkopino ottaa vallan (ja kuten tiedämme, se toteutetaan ydintilassa). Seuraavaksi palvelinsolmu vastaanottaa kyseisen datan tai metadatan sisältävän paketin ja käskee taustatallennusmoduulia (eli paikallista FS:ää, joka toimii ydintilassa) tallentamaan kaiken tämän. Olemme siis vähentäneet kysymyksen siihen, missä "lähetys" ja "vastaanotto" moduulien pitäisi toimia. Jos jokin näistä moduuleista toimii käyttäjätilassa, tämä johtaa väistämättä kontekstin vaihtamiseen (johtuen tarpeesta käyttää ydinpalveluita). Tällaisten kytkimien määrä riippuu toteutuksen yksityiskohdista.
Jos tällaisia kytkimiä on useita, tallennuskapasiteetti (I/O-suorituskyky) laskee. Jos taustamuistisi koostuu hitaista levyistä, et huomaa merkittävää pudotusta. Mutta jos sinulla on nopeat levyt (SSD, NVRAM jne.), kontekstin vaihtamisesta tulee jo "pullonkaula" ja kontekstin vaihtamista säästämällä voidaan parantaa merkittävästi suorituskykyä. Tavallinen tapa säästää rahaa on siirtää moduuleja ydintilaan. Huomasimme esimerkiksi, että 9p-palvelimen siirtäminen QEMU:sta isäntäkoneen ytimeen johtaa kolminkertaiseen VirtFS-suorituskykyyn.
Tämä ei tietenkään ole verkko-FS, mutta se heijastaa täysin asioiden olemusta. Tämän optimoinnin haittapuoli on siirrettävyysongelmat. Joillekin jälkimmäinen voi olla kriittinen. Esimerkiksi GlusterFS:ssä ei ole lainkaan moduuleja ytimessä. Tämän ansiosta se toimii nyt monilla alustoilla, mukaan lukien NetBSD.
Mitä käsitteitä paikalliset FS:t voisivat lainata verkkokonsepteilta ja päinvastoin?
Nykyään verkon FS:illä on pääsääntöisesti lisäosia paikallisten FS:ien päälle, joten en oikein ymmärrä, kuinka voit lainata jotain jälkimmäisistä. No, todellakin, ajatellaan 4 hengen yritystä, jossa jokainen tekee oman hommansa: yksi jakaa, toinen lähettää, kolmas vastaanottaa, neljäs varastoi. Ja kysymys, mitä yritys voi lainata sitä varastoivalta työntekijältään, kuulostaa jotenkin väärältä (sillä on jo ollut, mitä se olisi voinut lainata häneltä pitkään).
Mutta paikallisilla FS:llä on paljon opittavaa verkkopalveluista. Ensinnäkin sinun pitäisi oppia heiltä, kuinka loogisia volyymeja voidaan yhdistää korkealle tasolle. Nyt ns "Kehittyneet" paikalliset tiedostojärjestelmät yhdistävät loogisia asemia yksinomaan LVM:ltä lainatun "virtuaalilaitteen" teknologian avulla (sama tarttuva kerrosvirhe, joka toteutettiin ensimmäisen kerran ZFS:ssä). Toisin sanoen virtuaalisten osoitteiden (lohkonumeroiden) kääntäminen todellisiksi ja takaisin tapahtuu alhaisella tasolla (eli sen jälkeen, kun tiedostojärjestelmä on lähettänyt I/O-pyynnön).
Huomaa, että laitteiden lisääminen ja poistaminen lohkokerrokselle järjestettyihin loogisiin tilavuuksiin (ei peileihin) johtaa ongelmiin, joista tällaisten "ominaisuuksien" toimittajat ovat vaatimattomasti vaiti. Puhun pirstoutumisesta oikeilla laitteilla, jotka voivat saavuttaa hirvittäviä arvoja, kun taas virtuaalilaitteella kaikki on kunnossa. Harvat ihmiset ovat kuitenkin kiinnostuneita virtuaalisista laitteista: kaikki ovat kiinnostuneita siitä, mitä todellisilla laitteillasi tapahtuu. Mutta ZFS:n kaltainen FS (sekä mikä tahansa FS yhdessä LVM:n kanssa) toimii vain virtuaalilevylaitteiden kanssa (varaa virtuaalilevyosoitteita ilmaisista, eheyttää nämä virtuaalilaitteet jne.). Eikä heillä ole aavistustakaan siitä, mitä oikeissa laitteissa tapahtuu!
Kuvittele nyt, että sinulla on nolla hajanaisuutta virtuaalilaitteella (eli sinulla on vain yksi jättimäinen laajuus asuu siellä), lisäät levyn loogiseen taltioosi ja poistat sitten toisen satunnaisen levyn loogiselta taltioltasi ja tasapainotat sitten uudelleen. Ja niin monta kertaa. Ei ole vaikea kuvitella, että virtuaalilaitteella elät edelleen saman verran, mutta todellisilla laitteilla et näe mitään hyvää.
Pahinta on, ettet pysty edes korjaamaan tätä tilannetta! Ainoa asia, jonka voit tehdä tässä, on pyytää tiedostojärjestelmää eheyttämään virtuaalinen laite. Mutta hän kertoo sinulle, että kaikki on hienoa siellä - on vain yksi laajuus, pirstoutuminen on nolla, eikä se voi olla parempi! Joten lohkotasolle järjestetyt loogiset volyymit eivät ole tarkoitettu laitteiden toistuvaan lisäämiseen/poistamiseen. Hyvällä tavalla sinun tarvitsee vain koota looginen taltio lohkotasolla, antaa se tiedostojärjestelmälle ja sitten tehdä sille mitään.
Lisäksi riippumattomien FS+LVM-alijärjestelmien yhdistelmä ei salli loogisia volyymeja yhdistävien asemien erilaisen luonteen huomioon ottamista. Oletetaan todellakin, että olet koonnut loogisen taltion kiintolevy- ja puolijohde-laitteista. Mutta sitten edellinen vaatii eheyttämisen, jälkimmäinen ei. Jälkimmäistä varten sinun on lähetettävä hylkäyspyyntöjä, mutta ensimmäiselle ei jne. Tässä yhdistelmässä on kuitenkin melko vaikeaa osoittaa tällaista selektiivisyyttä.
Huomaa, että kun olet luonut oman LVM:n tiedostojärjestelmään, tilanne ei parane juurikaan. Lisäksi tekemällä näin teet lopun mahdollisuudesta parantaa sitä tulevaisuudessa. Tämä on erittäin huono. Erityyppiset asemat voivat toimia samassa koneessa. Ja jos tiedostojärjestelmä ei tee eroa niiden välillä, niin kuka tekee?
Toinen ongelma on odottamassa ns. "Write-Anywhere" -tiedostojärjestelmät (tämä sisältää myös Reiser4:n, jos määritit sopivan tapahtumamallin asennuksen aikana). Tällaisten tiedostojärjestelmien on tarjottava eheytystyökaluja, jotka ovat voimaltaan ennennäkemättömiä. Ja matalan tason äänenvoimakkuuden hallinta ei auta tässä, vaan vain häiritsee. Tosiasia on, että tällaisella hallintaohjelmalla FS tallentaa kartan vain yhden laitteen - virtuaalisen - ilmaisista lohkoista. Näin ollen voit eheyttää vain virtuaalisen laitteen. Tämä tarkoittaa, että eheytysohjelmasi toimii pitkään, pitkään valtavassa yksittäisessä virtuaaliosoitetilassa.
Ja jos sinulla on paljon käyttäjiä, jotka kirjoittavat satunnaisia korvauksia, tällaisen eheyttäjän hyödyllinen vaikutus pienenee nollaan. Järjestelmäsi alkaa väistämättä hidastua, ja sinun tarvitsee vain ristiä kätesi pettymysdiagnoosin "rikkinäinen suunnittelu" edessä. Useat samassa osoiteavaruudessa toimivat eheyttäjät vain häiritsevät toisiaan. On täysin eri asia, jos ylläpidät omaa karttaa ilmaisista lohkoista jokaiselle oikealle laitteelle. Tämä rinnastaa tehokkaasti eheytysprosessin.
Mutta tämä voidaan tehdä vain, jos sinulla on korkean tason looginen äänenvoimakkuuden hallinta. Paikallisia tiedostojärjestelmiä, joissa on tällaisia johtajia, ei ollut aiemmin (ainakaan minä tiedä niistä). Vain verkkotiedostojärjestelmissä (esimerkiksi GlusterFS) oli tällaisia hallintaohjelmia. Toinen erittäin tärkeä esimerkki on volyymin eheyden tarkistus (fsck) -apuohjelma. Jos tallennat oman itsenäisen karttasi vapaista lohkoista kullekin alivolyymille, loogisen tilavuuden tarkistusmenettely voidaan rinnastaa tehokkaasti. Toisin sanoen loogiset volyymit korkean tason johtajien kanssa skaalautuvat paremmin.
Lisäksi matalan tason äänenvoimakkuuden hallintaohjelmilla et voi järjestää täysimittaisia tilannekuvia. LVM- ja ZFS-tyyppisillä tiedostojärjestelmillä voit ottaa vain paikallisia tilannekuvia, mutta et globaaleja tilannekuvia. Paikallisten tilannekuvien avulla voit perua välittömästi vain tavalliset tiedostotoiminnot. Ja kukaan siellä ei peruuta operaatioita loogisilla volyymeilla (laitteiden lisääminen/poistaminen). Katsotaanpa tätä esimerkin avulla. Jossain vaiheessa, kun sinulla on kahden laitteen A ja B looginen määrä, jotka sisältävät 100 tiedostoa, otat tilannekuvan järjestelmästä S ja luot sitten toiset sata tiedostoa.
Tämän jälkeen lisäät laitteen C taltioon ja lopuksi palautat järjestelmäsi tilannekuvaksi S. Kysymys: Kuinka monta tiedostoa ja laitetta looginen asemasi sisältää sen jälkeen, kun se on palautettu S:ään? Tiedostoja tulee olemaan 100, kuten ehkä arvasit, mutta laitteita on 3 - nämä ovat samat laitteet A, B ja C, vaikka tilannevedoksen luomishetkellä järjestelmässä oli vain kaksi laitetta (A ja B ). Laitteen C lisäystoiminto ei peruuntunut, ja jos poistat nyt laitteen C tietokoneesta, se turmelee tietosi, joten ennen poistamista sinun on ensin suoritettava kallis toimenpide laitteen poistamiseksi loogisen tasapainotuksen tasosta, mikä hajottaa kaikki tiedot laitteesta C laitteisiin A ja B. Mutta jos FS tukee globaaleja tilannekuvia, tällaista tasapainotusta ei tarvita, ja välittömän palautuksen jälkeen S:ään voit poistaa laitteen C turvallisesti tietokoneesta.
Joten globaalit tilannevedokset ovat hyviä, koska niiden avulla voit välttää laitteen kalliin poistamisen (lisäyksen) loogiselta taltiolta (loogiseen taltioon), jossa on suuri määrä dataa (tietysti, jos muistat ottaa järjestelmästäsi tilannevedoksen) oikeaan aikaan). Haluan muistuttaa, että tilannekuvien luominen ja tiedostojärjestelmän palauttaminen niihin ovat välittömiä toimintoja. Voi herää kysymys: kuinka on edes mahdollista peruuttaa välittömästi kolme päivää kestänyt operaatio loogisella volyymilla? Mutta se on mahdollista! Edellyttäen, että tiedostojärjestelmäsi on suunniteltu oikein. Keksin ajatuksen tällaisista "3D-snapshots" -kuvista kolme vuotta sitten, ja viime vuonna patentoin tämän tekniikan.
Seuraava asia, joka paikallisten FS:iden tulisi oppia verkkopalvelimista, on tallentaa metatiedot eri laitteille samalla tavalla kuin verkon FS:t tallentavat ne erillisiin koneisiin (ns. metatietopalvelimiin). On sovelluksia, jotka toimivat ensisijaisesti metatietojen kanssa, ja näitä sovelluksia voidaan nopeuttaa huomattavasti sijoittamalla metatiedot kalliille korkean suorituskyvyn tallennuslaitteille. FS+LVM-yhdistelmällä et pysty osoittamaan tällaista selektiivisyyttä: LVM ei tiedä, mitä sille välittyneessä lohkossa on (tiedot siellä tai metatiedot).
Et saa paljon hyötyä oman matalan tason LVM:n toteuttamisesta FS:ssä verrattuna FS+LVM-yhdistelmään, mutta se, mitä voit tehdä erittäin hyvin, on sotkea FS niin, että myöhemmin sen koodin kanssa työskentely on mahdotonta. ZFS ja Btrfs, jotka ryntäsivät virtuaalisilla laitteilla, ovat kaikki selviä esimerkkejä siitä, kuinka kerrosrikkomus tappaa järjestelmän arkkitehtonisesti. Joten miksi minä olen tämä kaikki? Lisäksi sinun ei tarvitse asentaa omaa matalan tason LVM:ää tiedostojärjestelmään. Sen sijaan sinun on koottava laitteet loogisiksi taltioiksi korkealla tasolla, kuten jotkut verkkotiedostojärjestelmät tekevät eri koneiden (tallennussolmujen) kanssa. Totta, he tekevät tämän inhottavalla tavalla huonojen algoritmien käytön vuoksi.
Esimerkkejä aivan hirveistä algoritmeista ovat DHT-kääntäjä GlusterFS-tiedostojärjestelmässä ja ns. CRUSH-kartta Ceph-tiedostojärjestelmässä. Yksikään näkemistäni algoritmeista ei tyydyttänyt minua yksinkertaisuuden ja hyvän skaalautuvuuden suhteen. Joten minun piti muistaa algebra ja keksiä kaikki itse. Vuonna 2015 kokeillessani nippuja hash-funktioiden yli, keksin ja patentoin jotain, joka sopii minulle. Nyt voin sanoa, että yritys panna tämä kaikki käytäntöön onnistui. En näe uudessa lähestymistavassa skaalautuvuusongelmia.
Kyllä, jokainen alilevy vaatii erillisen rakenteen, kuten superblock-muistin. Onko tämä kovin pelottavaa? Yleensä en tiedä, kuka "keittää valtameren" ja luo loogisia määriä satoja tuhansia tai useampia laitteita yhdelle paikalliselle koneelle. Jos joku voi selittää tämän minulle, olisin erittäin kiitollinen. Sillä välin tämä on minulle markkinointipaskaa.
Miten muutokset ytimen lohkolaitealijärjestelmässä (esimerkiksi blk-mq:n ilmestyminen) vaikuttivat FS-toteutuksen vaatimuksiin?
Niillä ei ollut vaikutusta. En tiedä mitä tapahtuisi lohkokerroksessa, mikä tekisi tarpeelliseksi suunnitella uusi FS. Näiden osajärjestelmien vuorovaikutusrajapinta on erittäin huono. Kuljettajan puolelta FS:ään pitäisi vaikuttaa vain uudentyyppisten asemien ilmestyminen, joihin ensin säädetään lohkokerros ja sitten FS (reiser4:lle tämä tarkoittaa uusien laajennusten ilmestymistä).
Merkitseekö uudentyyppisten mediatyyppien ilmaantuminen (esimerkiksi SMR tai SSD-levyjen yleistyminen) pohjimmiltaan uusia haasteita tiedostojärjestelmän suunnittelulle?
Joo. Ja nämä ovat normaaleja kannustimia FS:n kehitykselle. Haasteet voivat olla erilaisia ja täysin odottamattomia. Olen esimerkiksi kuullut asemista, joissa I/O-toiminnon nopeus riippuu suuresti datan koosta ja sen poikkeamasta. Linuxissa, jossa FS-lohkon koko ei voi ylittää sivun kokoa, tällainen asema ei oletusarvoisesti näytä kaikkia ominaisuuksiaan. Jos tiedostojärjestelmäsi on kuitenkin suunniteltu oikein, voit saada siitä paljon enemmän irti.
Kuinka moni ihminen työskentelee tällä hetkellä Reiser4-koodin parissa sinun lisäksi?
Vähemmän kuin haluaisin, mutta en myöskään koe akuuttia resurssipulaa. Olen enemmän kuin tyytyväinen Reiser4:n kehitysvauhtiin. En aio "ajaa hevosia" - tämä ei ole oikea alue. Täällä "jos ajat hiljaisemmin, jatkat matkaa!" Nykyaikainen tiedostojärjestelmä on monimutkaisin ydinosajärjestelmä, jonka väärät suunnittelupäätökset voivat kumota seuraavien vuosien ihmisen työn.
Tarjoamalla vapaaehtoisia toteuttamaan jotain, takaan aina, että ponnistelut johtavat varmasti oikeaan lopputulokseen, jolle voi olla kysyntää vakavissa tarpeissa. Kuten ymmärrät, tällaisia takuita ei voi olla montaa kerralla. Samaan aikaan en voi sietää "hahmoja", jotka häpeämättömästi mainostavat ilmeisen käyttökelvottoman ohjelmiston "ominaisuuksia", pettääkseen satoja käyttäjiä ja kehittäjiä ja samalla istuvat ja hymyilevät ytimen huippukokouksissa.
Onko mikään yritys ilmaissut haluavansa tukea Reiser4:n kehitystä?
Kyllä, sellaisia ehdotuksia oli, mm. ja suurelta myyjältä. Mutta tätä varten minun piti muuttaa toiseen maahan. Valitettavasti en ole enää 30-vuotias, en voi irtautua ja lähteä sillä tavalla ensimmäisestä vihellyksestä.
Mitä ominaisuuksia Reiser4:stä puuttuu tällä hetkellä?
Yksinkertaisille taltioille ei ole "muuta kokoa" -toimintoa, joka on samanlainen kuin ReiserFS(v3). Lisäksi tiedostotoiminnot DIRECT_IO-lipulla eivät haittaisi. Seuraavaksi haluaisin pystyä erottelemaan taltion "semanttisiin alivolyymeihin", joilla ei ole kiinteää kokoa ja jotka voidaan asentaa itsenäisiksi taltioiksi. Nämä ongelmat ovat hyviä aloittelijoille, jotka haluavat kokeilla käsiään "oikeassa".
Ja lopuksi haluaisin verkon loogisia volyymeja yksinkertaisella toteutuksella ja hallinnolla (nykyaikaiset algoritmit jo sallivat tämän). Mutta mitä Reiser4:llä ei varmasti koskaan tule olemaan, on RAID-Z, scrubs, vapaan tilan välimuistit, 128-bittiset muuttujat ja muut markkinointihullut, jotka syntyivät joidenkin tiedostojärjestelmien kehittäjien ideoiden puutteen taustalla.
Voidaanko kaikki tarvittava toteuttaa laajennuksilla?
Jos puhumme vain liitännöistä ja niitä toteuttavista laajennuksista (moduuleista), ei kaikkea. Mutta jos esität myös suhteita näille rajapinnoille, sinulla on muun muassa käsitteet korkeammista polymorfismista, joilla voit jo tulla toimeen. Kuvittele, että olet hypoteettisesti pysäyttänyt oliokeskeisen ajonaikaisen järjestelmän, muuttanut käskyosoittimen arvon osoittamaan toiseen laajennukseen, joka toteuttaa saman X-rajapinnan, ja vapauttanut sitten järjestelmän, jotta se jatkaa suorittamista.
Jos loppukäyttäjä ei huomaa tällaista "korvausta", sanotaan, että järjestelmällä on nollakertainen polymorfismi X-rajapinnassa (tai järjestelmä on heterogeeninen X-rajapinnassa, mikä on sama asia). Jos nyt sinulla ei ole vain joukko rajapintoja, vaan niissä on myös suhteita (rajapintakaavio), voit ottaa käyttöön korkeamman asteen polymorfismeja, jotka luonnehtivat järjestelmän heterogeenisyyttä jo minkä tahansa rajapinnan "naapurustossa". Otin tällaisen luokituksen käyttöön kauan sitten, mutta valitettavasti sitä ei koskaan tapahtunut.
Joten pluginien ja tällaisten korkeampien polymorfismien avulla voit kuvata mitä tahansa tunnettua ominaisuutta sekä "ennustaa" niitä, joita ei ole koskaan edes mainittu. En ole pystynyt tiukasti todistamaan tätä, mutta en myöskään tiedä vielä vastaesimerkkiä. Yleisesti ottaen tämä kysymys muistutti minua Felix Kleinin "Erlangen-ohjelmasta". Kerran hän yritti esittää kaiken geometrian algebran (erityisesti ryhmäteorian) haarana.
Nyt pääkysymykseen - miten Reiser4:n promootiossa pääytimeen menee? Oliko tämän tiedostojärjestelmän arkkitehtuurista julkaisuja, joista puhuit viime haastattelussa? Kuinka relevantti tämä kysymys on sinun näkökulmastasi?
Yleisesti ottaen olemme pyytäneet pääsyä päähaaraan kolmen vuoden ajan. Reiserin viimeinen kommentti julkisessa säikeessä, jossa vetopyyntö tehtiin, jäi vastaamatta. Joten kaikki lisäkysymykset eivät ole meitä varten. En henkilökohtaisesti ymmärrä, miksi meidän täytyy "sulautua" tiettyyn käyttöjärjestelmään. Linuxissa valo ei lähentynyt kuin kiila. Joten siellä on erillinen arkisto, jossa on useita haaraportteja eri käyttöjärjestelmille. Kuka sitä tarvitsee, voi kloonata vastaavan portin ja tehdä sillä mitä haluaa (lisenssin sisällä tietysti). No, jos joku ei tarvitse sitä, se ei ole minun ongelmani. Tässä vaiheessa ehdotan, että kysymys "ylennyksestä Linuxin pääytimeen" on ratkaistu.
FS-arkkitehtuuria käsittelevät julkaisut ovat tärkeitä, mutta toistaiseksi olen löytänyt aikaa vain uusille tuloksilleni, joita pidän tärkeämpänä. Toinen asia on, että olen matemaatikko, ja matematiikassa mikä tahansa julkaisu on tiivistelmä lauseista ja niiden todisteista. Siellä julkaiseminen ilman todisteita on merkki huonosta mausta. Jos todistan tai kiistän perusteellisesti jonkin väitteen FS:n arkkitehtuurista, niin tuloksena on sellaisia kasoja, joista on melko vaikea päästä läpi. Kuka sitä tarvitsee? Luultavasti tästä syystä kaikki säilyy edelleen vanhassa muodossaan - lähdekoodi ja siihen liittyvät kommentit.
Mitä uutta Reiser4:ssä viime vuosina?
Kauan odotettu vakaus on vihdoin toteutunut. Yksi viimeisistä ilmestyneistä oli bugi, joka johti "ei-poistamattomiin" hakemistoihin. Vaikeutena oli, että se ilmestyi vain nimien hajautustörmäysten taustalla ja tietyllä hakemistotietueiden sijainnilla puusolmussa. En kuitenkaan voi silti suositella Reiser4:ää tuotantoon: tätä varten sinun on tehtävä jonkin verran työtä aktiivisen vuorovaikutuksen kanssa tuotantojärjestelmän ylläpitäjien kanssa.
Saimme vihdoin toteuttaa pitkäaikaisen ideamme - erilaiset kaupankäyntimallit. Aikaisemmin Reiser4 käytti vain yhtä kovakoodattua Macdonald-Reiser-mallia. Tämä aiheutti suunnitteluongelmia. Erityisesti tilannekuvat eivät ole mahdollisia tällaisessa tapahtumamallissa - ne korruptoituu atomikomponentilla nimeltä "OVERWRITE SET". Reiser4 tukee tällä hetkellä kolmea tapahtumamallia. Yhdessä niistä (Write-Anywhere) atomikomponentti OVERWRITE SET sisältää vain järjestelmäsivut (kuvia levybittikartoista jne.), joita ei voi "valokuvata" (kana ja muna -ongelma).
Joten kuvat voidaan nyt toteuttaa parhaalla mahdollisella tavalla. Toisessa tapahtumamallissa kaikki muokatut sivut menevät vain OVERWRITE SETiin (eli se on pohjimmiltaan puhdasta kirjaamista). Tämä malli on niille, jotka valittivat Reiser4-osioiden nopeasta pirstoutumisesta. Nyt tässä mallissa osio ei hajoa nopeammin kuin ReiserFS (v3). Kaikki kolme olemassa olevaa mallia, tietyin varauksin, takaavat toimintojen atomiteetin, mutta myös mallit, joissa atomiteetti on menetetty ja jotka säilyttävät vain osan eheyden, voivat olla hyödyllisiä. Tällaiset mallit voivat olla hyödyllisiä kaikenlaisissa sovelluksissa (tietokannat jne.), jotka ovat jo ottaneet osan näistä toiminnoista. Näitä malleja on erittäin helppo lisätä Reiser4:ään, mutta en tehnyt sitä, koska kukaan ei kysynyt minulta, enkä henkilökohtaisesti tarvitse sitä.
Metatietojen tarkistussummat ilmestyivät ja äskettäin täydensin niitä "taloudellisilla" peileillä" (vielä epävakaa materiaali). Jos jonkin lohkon tarkistussumma epäonnistuu, Reiser4 lukee välittömästi vastaavan lohkon replikalaitteesta. Huomaa, että ZFS ja Btrfs eivät voi tehdä tätä: suunnittelu ei salli sitä. Siellä sinun on suoritettava erityinen taustan skannausprosessi nimeltä "scrub" ja odotettava, että se pääsee ongelmalliseen lohkoon. Ohjelmoijat kutsuvat tällaisia tapahtumia kuvaannollisesti "sauvoilla".
Ja lopuksi on ilmestynyt heterogeeniset loogiset taltiot, jotka tarjoavat kaikkea mitä ZFS, Btrfs, lohkokerros sekä FS+LVM-yhdistelmät eivät periaatteessa pysty tarjoamaan - rinnakkaisskaalaus, O(1)-levyosoitteen allokaattori, läpinäkyvä tiedonsiirto alivolyymien välillä. Jälkimmäisessä on myös käyttöliittymä. Nyt voit helposti siirtää kuumimmat tiedot asemasi tehokkaimpaan asemaan.
Lisäksi on mahdollista huuhdella kiireesti kaikki likaiset sivut tällaiselle asemalle, mikä nopeuttaa merkittävästi sovelluksia, jotka usein kutsuvat fsync(2):ta. Huomaan, että lohkokerroksen toiminnallisuus, nimeltään bcache, ei tarjoa tällaista toimintavapautta ollenkaan. Uudet loogiset volyymit perustuvat algoritmeihini (vastaavia patentteja on olemassa). Ohjelmisto on jo melko vakaa, sitä on täysin mahdollista kokeilla, mitata suorituskykyä jne. Ainoa haitta on, että toistaiseksi sinun on päivitettävä äänenvoimakkuuden kokoonpano manuaalisesti ja tallennettava se jonnekin.
Toistaiseksi olen onnistunut toteuttamaan ideani 10 prosenttia, mutta olen onnistunut vaikeimpana pitämässäni asiassa - loogisten volyymien yhdistämisen flash-proseduurilla, joka suorittaa kaikki lykätyt toiminnot reiser4:ssä. Tämä kaikki on vielä kokeellisessa "format41"-haarassa.
Läpäiseekö Reiser4 xfstests?
Ainakin minulle se teki, kun valmistelin viimeistä julkaisua.
Onko Reiser4:stä periaatteessa mahdollista tehdä verkko (klusteri) FS pluginien avulla?
Se on mahdollista ja jopa välttämätöntä! Jos luot verkkotiedoston oikein suunniteltuun paikalliseen tiedostojärjestelmään, lopputulos on erittäin vaikuttava! Nykyaikaisissa verkon FS:issä en ole tyytyväinen taustatallennustason olemassaoloon, joka toteutetaan millä tahansa paikallisella FS:llä. Tämän tason olemassaolo on täysin perusteeton. Verkon FS:n on oltava suoraan vuorovaikutuksessa lohkokerroksen kanssa, eikä se saa pyytää paikallista FS:ää luomaan muita palvelutiedostoja!
Yleensä tiedostojärjestelmien jakaminen paikallisiin ja verkkoon on pahasta. Se johtui XNUMX vuotta sitten käytettyjen algoritmien epätäydellisyydestä, joiden tilalle ei ole vielä ehdotettu mitään. Tämä on myös syynä turhien ohjelmistokomponenttien (eri palvelut jne.) syntymiseen. Hyvällä tavalla jokaiselle koneelle pitäisi olla vain yksi ydinmoduulin muodossa oleva FS ja joukko käyttäjän apuohjelmia - klusterisolmu. Tämä FS on sekä paikallinen että verkko. Eikä mitään muuta!
Jos mikään ei toimi Reiser4:n kanssa Linuxissa, haluaisin tarjota FS:n FreeBSD:lle (lainaus edellisestä haastattelusta: "...FreeBSD:llä... on akateemiset juuret... Ja tämä tarkoittaa, että suurella todennäköisyydellä me löytää yhteisen kielen kehittäjien kanssa"?
Joten kuten juuri huomasimme, kaikki on jo toiminut täydellisesti Linuxin kanssa: sille on erillinen toimiva Reiser4-portti arkistomme päähaaran muodossa. En ole unohtanut FreeBSD:tä! Tarjous! Olen valmis työskentelemään läheisessä yhteistyössä FreeBSD:n sisäpiirin hyvin tuntevien kanssa. Muuten: pidän heidän yhteisössään todella siitä, että siellä päätökset tekee päivitetty riippumattomien asiantuntijoiden neuvosto, jolla ei ole mitään tekemistä yhden pysyvän henkilön hallituksen pettämisen kanssa.
Miten arvioit Linux-käyttäjäyhteisön nykyään? Onko siitä tullut enemmän "poppia"?
Työni luonteen vuoksi minun on melko vaikea arvioida tätä. Useimmiten käyttäjät tulevat luokseni virheraportteja ja pyyntöjä korjata osio. Käyttäjät käyttäjinä. Jotkut ovat viisaampia, jotkut vähemmän. Kaikkia kohdellaan samalla tavalla. No, jos käyttäjä jättää ohjeeni huomiotta, niin anteeksi: ohitusmääräys tulee myös minun osaltani.
Onko mahdollista ennustaa tiedostojärjestelmien kehitystä seuraavien viiden tai kymmenen vuoden aikana? Mitkä ovat mielestäsi FS-kehittäjien suurimmat haasteet?
Kyllä, tällaista ennustetta ei ole vaikea tehdä. Varsinaisia tiedostojärjestelmiä ei ole kehitetty pitkään aikaan. Sellaisen vain ulkonäkö luodaan. Paikallisten tiedostojärjestelmien kehittäjät törmäsivät huonoon suunnitteluun liittyviin ongelmiin. Tässä on tehtävä varoitus. En pidä niin sanottua "tallennusta", "nuolemista" ja koodin siirtämistä kehitystä ja kehitystä. Enkä luokittele "Btrfs"-nimistä väärinkäsitystä kehitykseksi jo selittämieni syiden vuoksi.
Jokainen korjaustiedosto vain pahentaa ongelmiaan. Hyvin. ja aina on erilaisia "evankelistoja", joille "kaikki toimii". Periaatteessa nämä ovat koululaisia ja opiskelijoita, jotka ohittavat luentoja. Kuvittele vain: se toimii hänelle, mutta professori ei. Mikä adrenaliinikuuma tämä on! Minun näkökulmastani suurimman haitan aiheuttavat "käsityöläiset", jotka ryntäsivät innostuneesti "ruuvaamaan" Btrfs:n upeita ominaisuuksia kaikenlaisille kerroksille, kuten systemd, docker jne. - tämä muistuttaa jo metastaaseja.
Yritetään nyt tehdä ennuste viidestä kymmeneen vuodeksi. Olen jo lyhyesti listannut mitä teemme Reiser4:ssä. Päähaaste paikallisille FS-kehittäjille alkupäästä tulee olemaan (kyllä, siitä on jo tullut) kyvyttömyys tehdä kunnollista työtä palkalla. Ilman ideoita tietojen tallennuksen alalla he jatkavat näiden valitettavan VFS:n, XFS:n ja ext4:n korjaamista. VFS:n tilanne näyttää tätä taustaa vasten erityisen koomiselta, muistuttaen kiihkeää modernisointia ravintolassa, jossa ei ole kokkeja, eikä kokkeja odotetakaan.
Nyt VFS-koodi ilman ehtoja lukitsee useita muistisivuja samanaikaisesti ja kutsuu taustalla olevan FS:n toimimaan niillä. Tämä otettiin käyttöön Ext4:n suorituskyvyn parantamiseksi poistotoiminnoissa, mutta kuten on helppo ymmärtää, tällainen samanaikainen lukitus on täysin yhteensopimaton kehittyneiden tapahtumamallien kanssa. Eli et voi yksinkertaisesti lisätä tukea jollekin älykkäälle tiedostojärjestelmälle ytimeen. En tiedä mikä tilanne on muilla Linuxin alueilla, mutta mitä tulee tiedostojärjestelmiin, mikään kehitys täällä ei todennäköisesti ole yhteensopivaa Torvaldsin käytännössä harjoittaman politiikan kanssa (akateemiset projektit potkitaan pois, ja huijarit, jotka minulla ei ole aavistustakaan, mikä B-puu, loputtomat luottamushyvitykset myönnetään). Siksi kurssi asetettiin hitaaseen rappeutumiseen. Tietenkin he yrittävät kaikin voimin pitää sen "kehityksenä".
Lisäksi tiedostojärjestelmien "säilyttäjät", jotka ymmärtävät, että pelkällä "tallennustilalla" ei voi ansaita paljon, kokeilevat kätensä kannattavammassa liiketoiminnassa. Näitä ovat pääsääntöisesti hajautetut tiedostojärjestelmät ja virtualisointi. Ehkä he siirtävät muodikkaan ZFS:n muualle, missä sitä ei vielä ole. Mutta se, kuten kaikki ylävirran FS, muistuttaa uudenvuoden puuta: jos voit ripustaa päälle muita pieniä asioita, et pääse syvemmälle. Myönnän, että ZFS:n pohjalta on mahdollista rakentaa vakava yritysjärjestelmä, mutta koska nyt keskustelemme tulevaisuudesta, voin surullisena todeta, että ZFS on tässä suhteessa toivoton: tyypit ovat katkaisneet hapen virtuaalilaitteillaan. itselleen ja tuleville sukupolville kehittyäkseen. ZFS on menneisyyttä. Ja ext4 ja XFS eivät ole edes toissapäivänä.
On syytä mainita erikseen sensaatiomaisesta konseptista "seuraavan sukupolven Linux-tiedostojärjestelmä". Tämä on täysin poliittinen ja markkinointiprojekti, joka on luotu niin sanotusti mahdollisuuteen "kiinnittää tiedostojärjestelmien tulevaisuus" Linuxissa tiettyjen merkkien taakse. Tosiasia on, että Linux oli ennen "vain huvin vuoksi". Mutta nyt se on ensisijaisesti rahantekokone. Niitä tehdään kaikkeen mahdolliseen. Esimerkiksi hyvän ohjelmistotuotteen luominen on erittäin vaikeaa, mutta älykkäät "kehittäjät" ovat jo pitkään ymmärtäneet, että turhaa rasitusta ei tarvitse lainkaan: voit menestyksekkäästi myydä olemattomia ohjelmistoja, joita on julkistettu ja mainostettu kaikenlaisissa yleisöissä. tapahtumat - tärkeintä on, että esitysdiat sisältävät enemmän "ominaisuuksia".
Tiedostojärjestelmät sopivat tähän täydellisesti, sillä tuloksesta voi turvallisesti neuvotella kymmenen vuotta. No, jos joku valittaa myöhemmin juuri tämän tuloksen puutteesta, hän ei yksinkertaisesti ymmärrä mitään tiedostojärjestelmistä! Tämä muistuttaa taloudellista pyramidia: huipulla ovat seikkailijat, jotka aloittivat tämän sotkun, ja ne harvat, joilla oli "onnea": he "nostivat osingot", ts. sai rahaa kehitykseen, sai hyvin palkatun työn esimiehinä, "näytti" konferensseissa jne.
Seuraavaksi tulevat "epäonniset": he laskevat tappioita, käsittelevät käyttökelvottoman ohjelmistotuotteen tuotantoon ottamisesta aiheutuvia seurauksia jne. Niitä on paljon enemmän. No, pyramidin juurella on valtava joukko kehittäjiä, jotka "sahaavat" hyödytöntä koodia. He ovat suurimmat häviäjät, koska hukattua aikaa ei voida palauttaa. Tällaiset pyramidit ovat erittäin hyödyllisiä Torvaldsille ja hänen työtovereilleen. Ja mitä enemmän näitä pyramideja, sitä parempi heille. Tällaisten pyramidien ruokkimiseksi ytimeen voidaan ottaa mitä tahansa. Tietysti julkisuudessa he sanovat päinvastoin. Mutta en tuomitse sanoilla vaan teoilla.
Joten "tiedostojärjestelmien tulevaisuus Linuxissa" on jälleen yksi erittäin edistetty, mutta tuskin käyttökelpoinen ohjelmisto. Btrfs:n jälkeen suurella todennäköisyydellä tällaisen ”tulevaisuuden” paikan ottaa Bcachefs, joka on toinen yritys ylittää Linuxin lohkokerros tiedostojärjestelmällä (huono esimerkki on tarttuva). Ja mikä on tyypillistä: siellä on samat ongelmat kuin Btrfsissä. Epäilin tätä pitkään, ja sitten jotenkin en voinut vastustaa ja katsoin koodia - se on totta!
Bcachefs- ja Btrfs-julkaisujen kirjoittajat käyttivät FS:ään luodessaan aktiivisesti muiden lähteitä ymmärtäen heistä vain vähän. Tilanne muistuttaa kovasti lasten peliä "rikki puhelin". Ja voin karkeasti kuvitella, kuinka tämä koodi sisällytetään ytimeen. Itse asiassa kukaan ei näe "haravoja" (kaikki astuvat niiden päälle myöhemmin). Lukuisten koodin tyyliin liittyvien kiukuttelujen, olemattomista rikkomuksista esitettyjen syytösten jälkeen tehdään johtopäätös kirjoittajan "uskollisuudesta", kuinka hyvin hän "vuorovaikuttaa" muiden kehittäjien kanssa ja kuinka onnistuneesti tämä kaikki onnistuu. sitten myydään yrityksille.
Lopputulos ei kiinnosta ketään. Parikymmentä vuotta sitten ehkä olisin ollut kiinnostunut, mutta nyt kysymykset esitetään toisin: voidaanko tätä edistää niin, että tietyt ihmiset tulevat työllistymään seuraavan kymmenen vuoden aikana. Ja valitettavasti lopputulosta ei ole tapana ihmetellä.
Yleisesti ottaen suosittelen vahvasti, että et aloita tiedostojärjestelmän keksimistä uudelleen alusta. Koska edes merkittävät taloudelliset investoinnit eivät riitä saamaan jotain kilpailukykyistä kymmenen vuoden kuluttua. Tietenkin puhun vakavista projekteista, en niistä, jotka on tarkoitus "työntää" ytimeen. Joten tehokkaampi tapa ilmaista itseäsi on liittyä todelliseen kehitykseen, kuten me. Tämä ei tietenkään ole helppoa - mutta näin on kaikissa korkean tason projekteissa.
Ensin sinun on ratkaistava itsenäisesti tarjoamani ongelma. Sen jälkeen, vakuuttuneena aikomustenne vakavuudesta, aion auttaa. Perinteisesti käytämme vain omaa kehitystämme. Poikkeuksena ovat pakkausalgoritmit ja jotkin hash-funktiot. Emme lähetä kehittäjiä matkustamaan konferensseihin, emmekä sitten istu ja yhdistä muiden ideoita ("ehkä mitä tapahtuu"), kuten useimmissa startup-yrityksissä on tapana.
Kehitämme kaikki algoritmit itse. Olen tällä hetkellä kiinnostunut tiedontallennustieteen algebrallisista ja kombinatorisista näkökohdista. Erityisesti äärelliset kentät, asymptotiikka, epäyhtälöiden todisteet. Töitä on myös tavallisille ohjelmoijille, mutta minun on varoitettava heti: kaikki ehdotukset "katso toinen FS ja tee sama" jätetään huomiotta. Sinne tulevat myös korjaustiedostot, joiden tavoitteena on tiiviimpi integraatio Linuxin kanssa VFS:n kautta.
Meillä ei siis ole haravaa, mutta meillä on käsitys siitä, mihin meidän on siirryttävä, ja meillä on luottamus siihen, että tämä suunta on oikea. Tämä ymmärrys ei tullut taivaasta mannan muodossa. Haluan muistuttaa, että meillä on takanamme 29 vuoden kehityskokemus, kaksi tyhjästä kirjoitettua tiedostojärjestelmää. Ja sama määrä tietojen palautusohjelmia. Ja tämä on paljon!
Lähde: opennet.ru