S'ha publicat la segona entrevista a Eduard Shishkin, desenvolupador del sistema de fitxers Reiser4.
Per començar, recordeu als lectors on i per a qui treballeu.
Treballo com a arquitecte principal d'emmagatzematge a Huawei Technologies, Centre de Recerca Alemany. Al departament de virtualització m'ocupo de diversos aspectes de l'emmagatzematge de dades. Les meves activitats no estan relacionades amb un sistema operatiu específic.
Esteu compromesos amb la branca principal del nucli?
Molt poques vegades, i només si el meu empresari ho requereix. L'última vegada va ser fa uns tres anys, vaig enviar pedaços per augmentar el rendiment de l'emmagatzematge compartit en amfitrions mitjançant el protocol 9p (un altre nom d'aquest negoci és VirtFS). Aquí s'ha de fer una nota important: tot i que fa temps que treballo amb Linux, no n'he estat mai fan, és a dir, "respir de manera uniforme", com amb tota la resta. En particular, si noto un defecte, el puc assenyalar com a màxim una vegada. I perquè després puguis seguir algú i persuadir-lo, això no passarà.
Recordo que la darrera vegada, fa deu anys, vau ser bastant crític amb l'estil de desenvolupament del nucli. Des del vostre punt de vista (o potser corporatiu), ha canviat alguna cosa, la comunitat s'ha tornat més sensible o no? Si no, qui creus que és el culpable?
Mai vaig veure cap canvi a millor. El principal problema de la comunitat és la substitució de la ciència per tecnologies polítiques, les relacions personals, l'opinió majoritària, el populisme, els consells de "veus interiors", els compromisos podrits, qualsevol cosa que no sigui ciència. La informàtica, sigui el que es digui, és abans que res una ciència exacta. I si algú comença a proclamar el seu propi valor per a 2x2, diferent de 4, sota la bandera "Linux way" o amb una altra bandera, és poc probable que això provoqui res més que un dany.
Tots els problemes es deuen principalment a la incompetència i la manca d'educació dels qui prenen decisions. Si un directiu és incompetent, no és capaç de prendre una decisió objectiva i adequada. Si també és inculte, no és capaç de trobar un especialista competent que li doni l'assessorament adequat. Amb una alta probabilitat, l'elecció recaurà en un estafador que digui "coses aparentment correctes". Un entorn corrupte sempre es desenvolupa al voltant de líders solitaris incompetents. A més, la història no coneix excepcions en aquest sentit, i la comunitat n'és la confirmació més clara.
Com avalueu el progrés en el desenvolupament de Btrfs? Aquest FS va desfer-se de les malalties infantils? Com el col·loqueu per a vosaltres mateixos: com a FS "per a casa" o també per a ús corporatiu?
No me'n vaig desfer. Tot el que vaig esmentar fa 11 anys encara és actual. Un dels problemes amb Btrfs que el fa inadequat per a necessitats greus és el problema de l'espai lliure. Ni tan sols estic parlant del fet que se li demana a l'usuari que executi a la botiga per un disc nou en situacions en què qualsevol altre FS mostraria molt espai lliure a la partició. La impossibilitat de completar una operació en un volum lògic per manca d'espai lliure tampoc és el pitjor. El pitjor és que un usuari sense privilegis gairebé sempre pot, eludir qualsevol quota de disc, privar a tothom d'espai lliure en un temps força curt.
Sembla així (provat per al nucli Linux 5.12). S'inicia un script en un sistema acabat d'instal·lar, que en un bucle crea fitxers amb determinats noms al directori d'inici, hi escriu dades amb determinats desplaçaments i després esborra aquests fitxers. Després d'un minut d'execució d'aquest script, no passa res inusual. Després de cinc minuts, la part d'espai ocupat a la partició augmenta lleugerament. Després de dues o tres hores arriba al 50% (amb un valor inicial del 15%). I després de cinc o sis hores de treball, l'script es bloqueja amb l'error "no hi ha espai lliure a la partició". Després d'això, ja no podreu escriure ni tan sols un fitxer 4K a la vostra partició.
Es produeix una situació interessant: vas acabar sense escriure res a la partició i tot l'espai lliure (al voltant del 85%) va desaparèixer en algun lloc. L'anàlisi d'una secció subjecta a aquest atac revelarà molts nodes d'arbre que contenen només un element (un objecte equipat amb una clau), de diversos bytes de mida. És a dir, el contingut que ocupava anteriorment el 15% de l'espai del disc va resultar ser "untat" de manera uniforme a tota la partició, de manera que no hi ha cap lloc per escriure un fitxer nou, perquè la seva clau és més gran que tots els existents, i el lliure els blocs de la partició s'han esgotat.
A més, tot això ja passa a la configuració bàsica de Btrfs (sense cap instantània, subvolums, etc.), i no importa com decidiu emmagatzemar els cossos dels fitxers en aquest FS (com a "fragments" en un arbre, o com a extensions). de blocs sense format) - el resultat final serà el mateix.
No podreu sotmetre altres sistemes de fitxers aigües amunt a aquest atac (no importa el que us diguin). Vaig explicar la causa del problema fa molt de temps: es tracta d'una perversió completa del concepte de l'arbre B a Btrfs, que fa possible que degeneri de manera espontània o intencionada. En particular, sota determinades càrregues, el vostre sistema de fitxers "esfondrarà" contínuament durant el funcionament per si mateix, sense ajuda externa. Està clar que tot tipus de processos de fons "premsats" només salvaran el dia en escriptoris individuals.
Als servidors col·lectius, un atacant sempre podrà "avançar-se". L'administrador del sistema ni tan sols podrà determinar qui el va assetjar exactament. La manera més ràpida de solucionar aquest problema a Btrfs és restaurar l'estructura d'un arbre B normal, és a dir. redissenyant el format del disc i reescrivint parts importants del codi Btrfs. Això trigarà entre 8 i 10 anys, inclosa la depuració, sempre que els desenvolupadors segueixin estrictament els articles originals sobre els algorismes i estructures de dades rellevants i no juguin al joc del "telèfon trencat", com és habitual (i recomana) a "Linux". manera”.
Aquí també hem d'afegir el temps necessari perquè els desenvolupadors entenguin tot això. Aquí és on es fa més difícil. En tot cas, 10 anys no van ser suficients per entendre'ls. Bé, fins aleshores no pots esperar un miracle. No passarà en forma d'opció de muntatge "que tu i jo no sabíem", o en forma d'un pedaç que és "només una qüestió de negocis" per preparar. Per a cada "arreglament" tan precipitat presentaré un nou escenari de degeneració. Els arbres B són un dels meus temes preferits, i he de dir que aquestes estructures no toleren llibertats amb elles mateixes!
Com em poso Btrfs? Com una cosa que no es pot anomenar sistema de fitxers, i molt menys utilitzat. Perquè, per definició, l'FS és un subsistema del sistema operatiu responsable de la gestió eficaç del recurs "espai en disc", cosa que no veiem en el cas de Btrfs. Bé, imagina que has vingut a la botiga a comprar un rellotge per no arribar tard a la feina, i en comptes d'un rellotge et van vendre una graella elèctrica amb temporitzador per un màxim de 30 minuts. Per tant, la situació amb Btrfs és encara pitjor.
Mirant les llistes de correu, sovint em trobo amb l'afirmació que la gestió eficaç de l'espai en disc ja no és rellevant a causa de l'economia de les unitats. Això és un disbarat total. Sense un gestor d'espai de disc efectiu, el sistema operatiu es tornarà vulnerable i inutilitzable. Independentment de la capacitat dels discs de la vostra màquina.
M'agradaria demanar comentaris sobre la interrupció del suport de Btrfs a RHEL.
Aquí no hi ha res especial a comentar, tot està molt clar. També el tenien com a "avançament tecnològic". Per tant, no vaig passar per aquesta "visualització prèvia". No deixis que aquesta etiqueta pengi per sempre! Però no poden llançar un producte de disseny defectuós amb suport total. RHEL és una empresa, és a dir, relacions mercaderies-diners prescrites. Red Hat no pot intimidar els usuaris com ho fan a la llista de correu de Btrfs. Imagineu-vos la situació: un client que va pagar els seus diners guanyats pel disc i també vosaltres per l'assistència, vol entendre on va anar el seu espai al disc després de no escriure res. Què li contestaràs a això?
Més lluny. Els clients de Red Hat inclouen grans bancs i borses de canvi coneguts. Imagineu què passaria si estiguessin subjectes a atacs DoS basats en la vulnerabilitat esmentada a Btrfs. Qui creus que és el responsable d'això? A aquells que estiguin a punt d'assenyalar amb el dit la línia de la llicència GPL, on està escrit que l'autor no és responsable de res, de seguida els diré: "amaga'l!" Red Hat respondrà, i de tal manera que no sembli suficient! Però sé que Red Hat no s'enfronta a aquest tipus de problemes, donat el seu equip d'enginyers de control de qualitat especialment fort amb els quals vaig tenir l'oportunitat de treballar estretament en el meu temps.
Per què algunes empreses continuen donant suport a Btrfs en els seus productes empresarials?
Tingueu en compte que el prefix "empresa" al nom del producte no significa gaire. L'empresa és una mesura de responsabilitat integrada en la relació contractual amb el client. Només conec una empresa basada en GNU/Linux: RHEL. Tota la resta, des del meu punt de vista, només es presenta com una empresa, però no és una. I, finalment, si hi ha una demanda d'alguna cosa, sempre hi haurà una oferta (en el nostre cas, aquest és l'esmentat "suport"). Hi ha demanda per a absolutament tot, inclòs. i programari inutilitzable. Com es forma aquesta demanda i qui la alimenta és un altre tema.
Per tant, no trauria cap conclusió després que es rumoregi que Facebook ha desplegat Btrfs als seus servidors. A més, recomanaria mantenir amb cura les adreces d'aquests servidors en secret pels motius anteriors.
Per què s'ha fet tant d'esforç per netejar el codi XFS últimament? Després de tot, inicialment es tracta d'un sistema de fitxers de tercers, i ext4 ha estat estable durant molt de temps i té continuïtat amb les versions anteriors igualment estables. Quin interès té Red Hat en XFS? Té sentit desenvolupar activament dos sistemes de fitxers que tinguin un propòsit similar: ext4 i XFS?
No recordo què va motivar això. És molt possible que la iniciativa vingués de clients de Red Hat. Recordo que es van dur a terme investigacions d'aquest tipus: en alguns sistemes de fitxers des de aigües amunt es van crear un nombre gegantí d'objectes en discs de gamma alta de la nova generació. Segons els resultats, XFS es va comportar millor que ext4. Així que van començar a promocionar-lo com el més prometedor. En qualsevol cas, aquí no buscaria res de sensacional.
Per a mi, és com si haguessin substituït un punxó per sabó. No té sentit desenvolupar ext4 i XFS. Tots dos en paral·lel i qualsevol d'ells a escollir. D'això no en sortirà res de bo. Encara que, a la natura sovint hi ha situacions en què hi ha molt potencial de creixement, però no hi ha espai per créixer. En aquest cas, sorgeixen diversos nous creixements estranyament lleigs, als quals tothom assenyala amb el dit ("Oh, mira, què no veuràs en aquesta vida!").
Creus que el problema de la violació de la capa s'ha resolt (en sentit negatiu) amb l'arribada de les funcions de xifratge a ext4, F2FS (per no parlar de RAID a Btrfs)?
En general, la introducció de qualsevol nivell i la presa de decisions sobre la seva no violació sol ser una qüestió de política, i no em comprometo a comentar res aquí. Els aspectes objectius de la violació de la capa són de poc interès per a ningú, però podem considerar alguns d'ells utilitzant l'exemple de violació "des de dalt", és a dir, la implementació al FS de la funcionalitat que ja existeix a la capa de blocs. Aquesta "violació" es justifica amb rares excepcions. Per a cada cas, primer heu de demostrar dues coses: que és realment necessari i que el disseny del sistema no es veurà perjudicat en fer-ho.
Per exemple, la duplicació, que tradicionalment ha estat una activitat per a la capa de blocs, té sentit implementar-la a nivell del sistema de fitxers. Per diferents motius. Per exemple, la corrupció de dades "silenciosa" (bit rot) es produeix a les unitats de disc. És quan el dispositiu funciona correctament, però les dades del bloc es fan malbé inesperadament sota la influència d'un quàntic gamma dur emès per un quàsar llunyà, etc. El pitjor és si aquest bloc resulta ser un bloc del sistema FS (superbloc, bloc de mapa de bits, node d'arbre d'emmagatzematge, etc.), perquè sens dubte provocarà un pànic del nucli.
Tingueu en compte que els miralls que ofereix la capa de blocs (l'anomenat RAID 1) no us salvaran d'aquest problema. Bé, realment: algú hauria de comprovar les sumes de control i llegir la rèplica en cas de fallada? A més, té sentit reflectir no només tot, sinó només les metadades. Algunes dades importants (per exemple, fitxers executables d'aplicacions crítiques) es poden emmagatzemar com a metadades. En aquest cas, reben les mateixes garanties de seguretat. Té sentit confiar la protecció de les dades restants a altres subsistemes (potser fins i tot aplicacions d'usuari): hem proporcionat totes les condicions necessàries per a això.
Aquests miralls "econòmics" tenen dret a existir i només es poden organitzar de manera efectiva a nivell del sistema de fitxers. En cas contrari, la violació de capes està desordenant un subsistema amb codi duplicat pel bé d'alguns beneficis microscòpics. Un exemple sorprenent d'això és la implementació de RAID-5 mitjançant FS. Aquestes solucions (RAID / LVM propis al sistema de fitxers) maten aquest últim en termes arquitectònics. També cal assenyalar aquí que diversos tipus d'estafadors de màrqueting "posen en funcionament" la violació de capes. En absència d'idees, la funcionalitat que s'ha implementat durant molt de temps als nivells veïns s'afegeix als subsistemes, això es presenta com una nova característica extremadament útil i s'impulsa activament.
Reiser4 va ser acusat de violar els nivells "des de baix". A partir del fet que el sistema de fitxers no és monolític, com tots els altres, sinó modular, es va suposar que fa el que hauria de fer el nivell superior (VFS).
Es pot parlar de la mort de ReiserFS v3.6 i, per exemple, de JFS? Darrerament gairebé no han rebut cap atenció al nucli. Estan obsolets?
Aquí hem de definir què significa la mort d'un producte de programari. D'una banda, s'utilitzen amb èxit (al cap i a la fi, per això es van crear), és a dir, viuen. D'altra banda, no puc parlar per JFS (no en sé gaire), però ReiserFS (v3) és molt difícil d'adaptar a les noves tendències (provat a la pràctica). Això vol dir que en el futur els desenvolupadors no li prestaran atenció, sinó als que siguin més fàcils d'adaptar. D'aquest costat resulta que, per desgràcia, està mort en termes arquitectònics. No manipularia gens el concepte de "moralment obsolet". S'aplica bé, per exemple, a un armari, però no als productes de programari. Hi ha un concepte d'inferioritat i superioritat en alguna cosa. Puc dir absolutament que ReserFS v3 ara és inferior a Reiser4 en tot, però en alguns tipus de càrrega de treball és superior a tots els altres FS amunt.
Coneixeu el desenvolupament de FS Tux3 i HAMMER/HAMMER2 (FS per DragonFly BSD)?
Sí, ho sabem. A Tux3 una vegada em va interessar la tecnologia de les seves instantànies (els anomenats "punters de versió"), però a Reiser4 el més probable és que anem per una ruta diferent. He estat pensant a donar suport a les instantànies durant molt de temps i encara no he decidit com implementar-les per a volums Reiser4 senzills. El fet és que la nova tècnica de comptador de referència "mandra" proposada per Ohad Rodeh només funciona per als arbres B. No els tenim. Per a les estructures de dades que s'utilitzen a Reiesr4, els comptadors "mandrosos" no estan definits; per introduir-los, cal resoldre certs problemes algorísmics, que ningú encara no ha assumit.
Segons HAMMER: Vaig llegir un article del creador. No estic interessat. De nou, arbres B. Aquesta estructura de dades està irremediablement obsoleta. El vam abandonar el segle passat.
Com avalueu la demanda creixent de FS de clúster de xarxa com CephFS/GlusterFS/etc? Aquesta demanda significa un canvi en les prioritats dels desenvolupadors cap a FS de xarxa i una atenció insuficient a FS locals?
Sí, s'ha produït aquest canvi de prioritats. El desenvolupament dels sistemes de fitxers locals s'ha estancat. Per desgràcia, fer alguna cosa important per als volums locals ara és bastant difícil i no tothom ho pot fer. Ningú vol invertir en el seu desenvolupament. Això és més o menys el mateix que demanar a una organització comercial que destini diners per a la investigació matemàtica: sense cap entusiasme et preguntaran com pots guanyar diners amb un teorema nou. Ara, un FS local és una cosa que apareix màgicament "fora de la caixa" i "sempre hauria de funcionar", i si no funciona, provoca murmuracions sense adreçar-se com: "Sí, què estan pensant!"
D'aquí la manca d'atenció a l'FS local, tot i que encara hi ha molta feina en aquest àmbit. I sí, tothom ha recorregut a l'emmagatzematge distribuït, que es basa en sistemes de fitxers locals ja existents. Ara està molt de moda. La frase "Big Data" provoca una pujada d'adrenalina a molts, associant-la a conferències, tallers, grans sous, etc.
Què tan raonable és, en principi, implementar el sistema de fitxers de xarxa a l'espai del nucli més que a l'espai d'usuari?
Un enfocament molt raonable que encara no s'ha implementat enlloc. En general, la qüestió de en quin espai s'ha d'implementar un sistema de fitxers de xarxa és una "espasa de doble tall". Bé, mirem un exemple. El client va registrar dades en una màquina remota. Van caure a la seva memòria cau de pàgines en forma de pàgines brutes. Aquesta és la feina per a un sistema de fitxers de xarxa "porta d'enllaç prima" a l'espai del nucli. Aleshores, tard o d'hora, el sistema operatiu us demanarà que escriviu aquestes pàgines al disc per alliberar-les. A continuació, entra en joc el mòdul FS de xarxa d'enviament (enviament) d'IO. Determina a quina màquina servidor (node servidor) aniran aquestes pàgines.
Aleshores, la pila de xarxa pren el relleu (i, com sabem, s'implementa a l'espai del nucli). A continuació, el node del servidor rep aquest paquet amb dades o metadades i indica al mòdul d'emmagatzematge de fons (és a dir, el FS local que opera a l'espai del nucli) que enregistri totes aquestes coses. Per tant, hem reduït la pregunta a on haurien de funcionar els mòduls d'"enviament" i "recepció". Si algun d'aquests mòduls s'executa a l'espai d'usuari, això comportarà inevitablement un canvi de context (a causa de la necessitat d'utilitzar els serveis del nucli). El nombre d'aquests interruptors depèn dels detalls de la implementació.
Si hi ha molts commutadors d'aquest tipus, el rendiment d'emmagatzematge (rendiment d'E/S) disminuirà. Si el vostre emmagatzematge de fons està format per discs lents, no notareu una caiguda significativa. Però si teniu discs ràpids (SSD, NVRAM, etc.), el canvi de context ja es converteix en un "coll d'ampolla" i, estalviant en el canvi de context, el rendiment es pot augmentar significativament. La forma estàndard d'estalviar diners és moure mòduls a l'espai del nucli. Per exemple, vam trobar que moure el servidor 9p de QEMU al nucli de la màquina amfitrió comporta un augment de tres vegades en el rendiment de VirtFS.
Això, per descomptat, no és un FS de xarxa, però reflecteix completament l'essència de les coses. L'inconvenient d'aquesta optimització són els problemes de portabilitat. Per a alguns, aquest últim pot ser crític. Per exemple, GlusterFS no té cap mòdul al nucli. Gràcies a això, ara funciona en moltes plataformes, inclosa NetBSD.
Quins conceptes podrien agafar els FS locals dels de xarxa i viceversa?
Avui en dia, els FS de xarxa, per regla general, tenen complements sobre els FS locals, de manera que no entenc gaire com es pot demanar prestat alguna cosa d'aquests últims. Bé, efectivament, considerem una empresa de 4 treballadors, en la qual cadascú fa el seu: un distribueix, un altre envia, el tercer rep, el quart emmagatzema. I la pregunta, què pot demanar en préstec l'empresa al seu empleat que l'emmagatzema, sona d'alguna manera incorrecta (ja té el que li podria haver manllevat durant molt de temps).
Però els FS locals tenen molt a aprendre dels de xarxa. En primer lloc, hauríeu d'aprendre d'ells com agregar volums lògics a un alt nivell. Ara l'anomenat Els sistemes de fitxers locals "avançats" agreguen volums lògics exclusivament utilitzant tecnologia de "dispositiu virtual" prestada de LVM (la mateixa violació de capes infeccioses que es va implementar per primera vegada a ZFS). Dit d'una altra manera, la traducció d'adreces virtuals (números de bloc) a reals i de tornada es produeix a un nivell baix (és a dir, després que el sistema de fitxers hagi emès una sol·licitud d'E/S).
Tingueu en compte que afegir i eliminar dispositius als volums lògics (no miralls) disposats a la capa de blocs comporta problemes sobre els quals els proveïdors d'aquestes "característiques" estan modestament silenciosos. Parlo de fragmentació en dispositius reals, que poden assolir valors monstruosos, mentre que en un dispositiu virtual tot està bé. No obstant això, poca gent està interessada en els dispositius virtuals: tothom està interessat en el que està passant als teus dispositius reals. Però els FS similars a ZFS (així com qualsevol FS en conjunció amb LVM) només funcionen amb dispositius de disc virtual (assignar adreces de disc virtual entre les gratuïtes, desfragmentar aquests dispositius virtuals, etc.). I no tenen ni idea del que passa als dispositius reals!
Ara imagineu-vos que teniu zero fragmentació al dispositiu virtual (és a dir, només teniu una extensió gegant que hi viu), afegiu un disc al vostre volum lògic i, a continuació, elimineu un altre disc aleatori del vostre volum lògic i, a continuació, reequilibreu. I tantes vegades. No és difícil imaginar que al dispositiu virtual encara tindreu la mateixa extensió vivint, però en dispositius reals no veureu res de bo.
El pitjor és que ni tan sols ets capaç de corregir aquesta situació! L'únic que podeu fer aquí és demanar al sistema de fitxers que desfragmenti el dispositiu virtual. Però ella et dirà que tot és genial allà: només hi ha una mesura, la fragmentació és zero i no pot ser millor! Per tant, els volums lògics disposats a nivell de bloc no estan pensats per a l'addició/eliminació repetida de dispositius. En bona manera, només cal que muntis un volum lògic a nivell de bloc una vegada, que l'entregis al sistema de fitxers i després no facis res més amb ell.
A més, la combinació de subsistemes FS+LVM independents no permet tenir en compte la diferent naturalesa de les unitats a partir de les quals s'agreguen els volums lògics. De fet, suposem que heu muntat un volum lògic des de HDD i dispositius d'estat sòlid. Però llavors el primer requerirà desfragmentació, i el segon no. Per als segons, cal emetre sol·licituds de descart, però per a les primeres, no, etc. Tanmateix, en aquesta combinació és bastant difícil demostrar aquesta selectivitat.
Tingueu en compte que després de crear el vostre propi LVM al sistema de fitxers, la situació no millora gaire. A més, fent això, poses fi a la perspectiva de millorar-lo en el futur. Això és molt dolent. A la mateixa màquina poden viure diferents tipus d'accionaments. I si el sistema de fitxers no els distingeix, qui ho farà?
Un altre problema està a l'espera de l'anomenat. Sistemes de fitxers "Write-Anywhere" (això també inclou Reiser4, si heu especificat el model transaccional adequat durant el muntatge). Aquests sistemes de fitxers han de proporcionar eines de desfragmentació sense precedents en el seu poder. I el gestor de volum de baix nivell no ajuda aquí, sinó que només s'interposa. El fet és que amb aquest gestor, el vostre FS emmagatzemarà un mapa de blocs gratuïts d'un sol dispositiu: un de virtual. En conseqüència, només podeu desfragmentar un dispositiu virtual. Això vol dir que el vostre desfragmentador funcionarà durant molt de temps en un únic espai enorme d'adreces virtuals.
I si teniu molts usuaris que fan sobreescritures aleatòries, l'efecte útil d'aquest desfragmentador es reduirà a zero. Inevitablement, el vostre sistema començarà a alentir-se i només haureu de plegar les mans davant del diagnòstic decebedor "disseny trencat". Diversos desfragmentadors que s'executen al mateix espai d'adreces només interferiran entre ells. És una qüestió completament diferent si manteniu el vostre propi mapa de blocs gratuïts per a cada dispositiu real. Això paral·lelitzarà efectivament el procés de desfragmentació.
Però això només es pot fer si teniu un gestor de volum lògic d'alt nivell. Els sistemes de fitxers locals amb aquests gestors no existien anteriorment (almenys, no els conec). Només els sistemes de fitxers de xarxa (per exemple GlusterFS) tenien aquests gestors. Un altre exemple molt important és la utilitat de comprovació d'integritat del volum (fsck). Si emmagatzemeu el vostre propi mapa independent de blocs lliures per a cada subvolum, el procediment per comprovar un volum lògic es pot paral·lelitzar de manera efectiva. En altres paraules, els volums lògics amb gestors d'alt nivell s'escalen millor.
A més, amb gestors de volum de baix nivell no podreu organitzar instantànies completes. Amb sistemes de fitxers similars a LVM i ZFS, només podeu fer instantànies locals, però no globals. Les instantànies locals us permeten revertir a l'instant només les operacions de fitxers habituals. I ningú no tornarà enrere les operacions amb volums lògics (afegir/eliminar dispositius). Vegem-ho amb un exemple. En algun moment, quan teniu un volum lògic de dos dispositius A i B que contenen 100 fitxers, feu una instantània del sistema S i després creeu un centenar de fitxers més.
Després d'això, afegiu el dispositiu C al vostre volum i, finalment, torneu el sistema a la instantània S. Pregunta: Quants fitxers i dispositius conté el vostre volum lògic després de tornar a S? Hi haurà 100 fitxers, com haureu endevinat, però hi haurà 3 dispositius: aquests són els mateixos dispositius A, B i C, tot i que en el moment en què es va crear la instantània només hi havia dos dispositius al sistema (A i B). ). L'operació d'afegir el dispositiu C no es va revertir i, si ara traieu el dispositiu C de l'ordinador, corromprà les vostres dades, de manera que abans de suprimir haureu de realitzar una operació costosa per eliminar el dispositiu del volum lògic de reequilibri, que dispersarà totes les dades del dispositiu C als dispositius A i B. Però si el vostre FS admetia instantànies globals, aquest reequilibri no seria necessari i, després d'un retorn instantani a S, podríeu eliminar el dispositiu C de l'ordinador amb seguretat.
Per tant, les instantànies globals són bones perquè us permeten evitar la costosa eliminació (afegir) d'un dispositiu d'un volum lògic (a un volum lògic) amb una gran quantitat de dades (per descomptat, si recordeu "capturar" el vostre sistema). en el moment adequat). Permeteu-me que us recordi que crear instantànies i tornar-hi el sistema de fitxers són operacions instantànies. Pot sorgir la pregunta: com és possible fins i tot revertir instantàniament una operació en un volum lògic que us va portar tres dies? Però és possible! Sempre que el vostre sistema de fitxers estigui dissenyat correctament. Vaig tenir la idea d'aquestes "instantànias 3D" fa tres anys, i l'any passat vaig patentar aquesta tècnica.
El següent que els FS locals haurien d'aprendre dels de xarxa és emmagatzemar metadades en dispositius separats de la mateixa manera que els FS de xarxa les emmagatzemen en màquines separades (els anomenats servidors de metadades). Hi ha aplicacions que funcionen principalment amb metadades, i aquestes aplicacions es poden accelerar molt col·locant les metadades en dispositius d'emmagatzematge d'alt rendiment cars. Amb la combinació FS+LVM, no podreu demostrar aquesta selectivitat: LVM no sap què hi ha al bloc que li heu passat (dades o metadades).
No obtindreu gaire benefici d'implementar el vostre propi LVM de baix nivell al FS en comparació amb la combinació FS+LVM, però el que podeu fer molt bé és desordenar el FS de manera que més tard es faci impossible treballar amb el seu codi. ZFS i Btrfs, que es van precipitar amb dispositius virtuals, són exemples clars de com la violació de capes mata el sistema en termes arquitectònics, doncs, per què sóc tot això? A més, no cal crear el vostre propi LVM de baix nivell al sistema de fitxers. En comptes d'això, heu d'agregar dispositius en volums lògics a un alt nivell, com fan alguns sistemes de fitxers de xarxa amb diferents màquines (nodes d'emmagatzematge). És cert que ho fan de manera repugnant a causa de l'ús d'algoritmes dolents.
Exemples d'algoritmes absolutament terribles són el traductor DHT al sistema de fitxers GlusterFS i l'anomenat mapa CRUSH al sistema de fitxers Ceph. Cap dels algorismes que vaig veure em va satisfer en termes de senzillesa i bona escalabilitat. Així que vaig haver de recordar l'àlgebra i inventar-ho tot jo mateix. L'any 2015, mentre experimentava amb paquets sobre funcions hash, vaig inventar i patentar alguna cosa que em convé. Ara puc dir que l'intent de posar en pràctica tot això va tenir èxit. No veig cap problema d'escalabilitat en el nou enfocament.
Sí, cada subvolum requerirà una estructura separada, com ara un superbloc a la memòria. Això fa molta por? En general, no sé qui "bullirà l'oceà" i crearà volums lògics de centenars de milers o més de dispositius en una màquina local. Si algú m'ho pot explicar, li estaré molt agraït. Mentrestant, per a mi això és una merda de màrqueting.
Com van afectar els canvis al subsistema del dispositiu de blocs del nucli (per exemple, l'aparició de blk-mq) els requisits per a la implementació de FS?
No van tenir cap impacte. No sé què passaria a la capa de blocs que faria necessari dissenyar un nou FS. La interfície d'interacció d'aquests subsistemes és molt pobra. Des del costat del controlador, l'FS només s'hauria de veure afectat per l'aparició de nous tipus de unitats, a les quals s'ajustarà primer la capa de blocs, i després l'FS (per a reiser4 això significarà l'aparició de nous connectors).
L'aparició de nous tipus de suports (per exemple, SMR o la ubiqüitat dels SSD) suposa nous reptes fonamentalment per al disseny del sistema de fitxers?
Sí. I aquests són incentius normals per al desenvolupament de FS. Els reptes poden ser diferents i completament inesperats. Per exemple, he sentit parlar de unitats on la velocitat d'una operació d'E/S depèn molt de la mida d'una dada i el seu desplaçament. A Linux, on la mida del bloc FS no pot superar la mida de la pàgina, aquesta unitat no mostrarà totes les seves capacitats per defecte. Tanmateix, si el vostre sistema de fitxers està dissenyat correctament, hi ha la possibilitat d'aprofitar-ne molt més.
Quantes persones estan treballant actualment amb el codi Reiser4 a més de tu?
Menys del que voldria, però tampoc no tinc una escassetat aguda de recursos. Estic més que satisfet amb el ritme de desenvolupament de Reiser4. No vaig a "conduir cavalls": aquesta no és la zona adequada. Aquí, "si condueixes més tranquil, seguiràs!" Un sistema de fitxers modern és el subsistema del nucli més complex, les decisions de disseny equivocades del qual poden desfer els anys posteriors de treball humà.
En oferir voluntaris per implementar alguna cosa, sempre garanteixo que els esforços certament conduiran al resultat correcte, que pot ser demandat per necessitats greus. Com enteneu, no hi pot haver moltes garanties alhora. Al mateix temps, no suporto les "figures" que promouen descaradament "funcions" de programari òbviament inutilitzable, enganyant centenars d'usuaris i desenvolupadors i, al mateix temps, seure i somriure a les cimeres del nucli.
Alguna empresa ha expressat la seva voluntat de donar suport al desenvolupament de Reiser4?
Sí, hi havia propostes d'aquest tipus, incl. i d'un gran venedor. Però per això vaig haver de mudar-me a un altre país. Malauradament, ja no tinc 30 anys, no puc separar-me i marxar així al primer xiulet.
Quines funcions falten actualment a Reiser4?
No hi ha cap funció de "canviar la mida" per a volums simples, similar a la que es troba a ReiserFS(v3). A més, les operacions de fitxers amb el senyalador DIRECT_IO no farien mal. A continuació, m'agradaria poder segregar un volum en "subvolums semàntics", que no tinguin una mida fixa i que es puguin muntar com a volums independents. Aquests problemes són bons per als principiants que volen provar la "cosa real".
I finalment, m'agradaria tenir volums lògics de xarxa amb una implementació i administració senzilles (els algorismes moderns ja ho permeten). Però el que definitivament Reiser4 no tindrà mai és RAID-Z, scrubs, memòria cau d'espai lliure, variables de 128 bits i altres disbarats de màrqueting que van sorgir en el context de l'escassetat d'idees entre els desenvolupadors d'alguns sistemes de fitxers.
Es pot implementar amb complements tot el que es pugui necessitar?
Si parlem només en termes d'interfícies i complements (mòduls) que els implementen, no tot. Però si també introduïu relacions en aquestes interfícies, aleshores, entre altres coses, tindreu els conceptes de polimorfismes superiors, amb els quals ja us podeu arreglar. Imagineu que, hipotèticament, heu congelat un sistema d'execució orientat a objectes, heu canviat el valor del punter d'instruccions per apuntar a un altre connector que implementa la mateixa interfície X i després heu descongelat el sistema perquè continuï executant-se.
Si l'usuari final no nota aquesta "substitució", diem que el sistema té un polimorfisme d'ordre zero a la interfície X (o el sistema és heterogeni a la interfície X, que és el mateix). Si ara no només disposeu d'un conjunt d'interfícies, sinó que també hi teniu relacions (gràfic de la interfície), podeu introduir polimorfismes d'ordres superiors, que caracteritzen l'heterogeneïtat del sistema ja al "barri" de qualsevol interfície. Vaig introduir aquesta classificació fa molt de temps, però, malauradament, no va passar mai.
Per tant, amb l'ajuda de connectors i polimorfismes tan elevats, podeu descriure qualsevol característica coneguda, així com "predir" aquelles que ni tan sols s'han esmentat. No he pogut demostrar-ho de manera estricta, però tampoc no conec encara un contraexemple. En general, aquesta pregunta em va recordar el "Programa Erlangen" de Felix Klein. En un moment va intentar representar tota la geometria com una branca de l'àlgebra (concretament, la teoria de grups).
Ara a la pregunta principal: com van les coses amb la promoció de Reiser4 al nucli principal? Hi va haver alguna publicació sobre l'arquitectura d'aquest sistema de fitxers de la qual vau parlar en l'última entrevista? Quina importància té aquesta pregunta des del vostre punt de vista?
En general, fa tres anys que demanem la inclusió a la branca principal. L'últim comentari de Reiser al fil públic on es va fer la sol·licitud d'extracció va romandre sense resposta. Així que totes les altres preguntes no són per a nosaltres. Personalment, no entenc per què hem de "fusionar-nos" en un sistema operatiu específic. A Linux, la llum no va convergir com una falca. Per tant, hi ha un dipòsit separat en el qual hi haurà diversos ports de branca per a diferents sistemes operatius. Qui ho necessiti pot clonar el port corresponent i fer-ne el que vulgui (dins de la llicència, és clar). Bé, si algú no ho necessita, no és el meu problema. En aquest punt, proposo considerar la qüestió de la "promoció al nucli principal de Linux" com a resolta.
Les publicacions sobre arquitectura FS són rellevants, però fins ara només he trobat temps per als meus nous resultats, que considero una prioritat més alta. Una altra cosa és que sóc matemàtic, i en matemàtiques qualsevol publicació és un resum de teoremes i les seves demostracions. Publicar qualsevol cosa allà sense proves és senyal de mal gust. Si demostro o rebutjo a fons qualsevol afirmació sobre l'arquitectura del FS, el resultat serà tal que serà bastant difícil de superar. Qui ho necessita? Probablement és per això que tot continua conservant la seva forma antiga: el codi font i els comentaris.
Què hi ha de nou a Reiser4 durant els darrers anys?
Per fi s'ha materialitzat l'esperada estabilitat. Un dels últims a aparèixer va ser un error que va provocar directoris "no esborrables". La dificultat era que només apareixia en el fons de col·lisions de hash de noms i amb una determinada ubicació dels registres de directoris en un node d'arbre. No obstant això, encara no puc recomanar Reiser4 per a la producció: per això cal que treballeu amb una interacció activa amb els administradors del sistema de producció.
Finalment vam aconseguir implementar la nostra idea de llarga data: diferents models de transaccions. Anteriorment, Reiser4 només executava un model Macdonald-Reiser codificat en dur. Això va crear problemes de disseny. En particular, les instantànies no són possibles en un model transaccional d'aquest tipus: seran corrompudes per un component atòmic anomenat "OVERWRITE SET". Actualment, Reiser4 admet tres models de transaccions. En un d'ells (Write-Anywhere), el component atòmic OVERWRITE SET inclou només pàgines del sistema (imatges de mapes de bits de disc, etc.), que no es poden "fotografiar" (el problema de la gallina i l'ou).
Així que les imatges ara es poden realitzar de la millor manera possible. En un altre model transaccional, totes les pàgines modificades només van al OVERWITE SET (és a dir, és essencialment pur diari). Aquest model és per a aquells que es queixaven de la ràpida fragmentació de les particions Reiser4. Ara, en aquest model, la vostra partició no es fragmentarà més ràpidament que amb ReiserFS (v3). Els tres models existents, amb algunes reserves, garanteixen l'atomicitat de les operacions, però també poden ser útils els models amb pèrdua d'atomicitat i conservant només la integritat de la secció. Aquests models poden ser útils per a tot tipus d'aplicacions (bases de dades, etc.), que ja han assumit algunes d'aquestes funcions. És molt fàcil afegir aquests models a Reiser4, però jo no ho vaig fer, perquè ningú m'ho va demanar, i jo personalment no ho necessito.
Van aparèixer les sumes de control de metadades i recentment les vaig complementar amb miralls "econòmics"" (material encara inestable). Si la suma de comprovació de qualsevol bloc falla, Reiser4 llegeix immediatament el bloc corresponent des del dispositiu de rèplica. Tingueu en compte que ZFS i Btrfs no poden fer això: el disseny no ho permet. Allà heu d'executar un procés especial d'exploració en segon pla anomenat "scrub" i esperar que arribi al bloc problemàtic. Els programadors, en sentit figurat, anomenen aquests esdeveniments "mulletes".
I, finalment, han aparegut volums lògics heterogenis que ofereixen tot el que ZFS, Btrfs, capa de blocs, així com les combinacions FS+LVM en principi no poden oferir: escala paral·lela, assignador d'adreces de disc O(1), migració de dades transparent entre subvolums. Aquest últim també té una interfície d'usuari. Ara podeu moure fàcilment les dades més actuals a la unitat de major rendiment del vostre volum.
A més, és possible netejar urgentment qualsevol pàgina bruta a una unitat d'aquest tipus, accelerant així significativament les aplicacions que sovint criden a fsync(2). Observo que la funcionalitat de la capa de blocs, anomenada bcache, no ofereix en absolut aquesta llibertat d'acció. Els nous volums lògics es basen en els meus algorismes (hi ha patents corresponents). El programari ja és bastant estable, és molt possible provar-lo, mesurar el rendiment, etc. L'únic inconvenient és que de moment cal actualitzar manualment la configuració del volum i emmagatzemar-lo en algun lloc.
Fins ara he pogut implementar les meves idees en un 10 per cent, però, he tingut èxit en el que considerava el més difícil: connectar volums lògics amb un procediment flash que realitza totes les accions diferides a reiser4. Tot això encara es troba a la branca experimental "format41".
Reiser4 passa xfstests?
Almenys ho va fer per a mi quan estava preparant l'últim llançament.
És possible, en principi, fer de Reiser4 un FS de xarxa (clúster) mitjançant connectors?
És possible, i fins i tot necessari! Si creeu un fitxer de xarxa basat en un sistema de fitxers local dissenyat correctament, el resultat serà molt impressionant! A les FS de xarxa modernes, no estic satisfet amb la presència d'un nivell d'emmagatzematge de fons, que s'implementa amb qualsevol FS local. L'existència d'aquest nivell és completament injustificada. L'FS de xarxa ha d'interaccionar directament amb la capa de blocs i no demanar a l'FS local que creï cap altre fitxer de servei!
En general, dividir els sistemes de fitxers en locals i de xarxa és del maligne. Va sorgir de la imperfecció dels algorismes que s'utilitzaven fa trenta anys, i en lloc dels quals encara no s'ha proposat res. Aquest és també el motiu de l'aparició d'una massa de components de programari innecessaris (diversos serveis, etc.). En bona manera, només hi hauria d'haver un FS en forma de mòdul del nucli i un conjunt d'utilitats d'usuari instal·lades a cada màquina: un node de clúster. Aquest FS és tant local com de xarxa. I res més!
Si res funciona amb Reiser4 a Linux, m'agradaria oferir un FS per a FreeBSD (cita d'una entrevista anterior: “...FreeBSD... té arrels acadèmiques... I això vol dir que amb un alt grau de probabilitat trobarà un llenguatge comú amb els desenvolupadors”)?
Així, com acabem de descobrir, tot ja ha funcionat perfectament amb Linux: hi ha un port Reiser4 que funciona per separat en forma de branca mestra del nostre dipòsit. No m'he oblidat de FreeBSD! Oferta! Estic preparat per treballar estretament amb aquells que coneixen bé l'interior de FreeBSD. Per cert: el que més m'agrada de la seva comunitat és que les decisions les prenen un consell actualitzat d'experts independents, que no té res a veure amb l'engany governamental d'una persona permanent.
Com valoreu la comunitat d'usuaris de Linux avui? S'ha tornat més "pop"?
Atesa la naturalesa del meu treball, em costa força avaluar-ho. La majoria dels usuaris vénen a mi amb informes d'errors i sol·licituds per arreglar la secció. Usuaris com a usuaris. Alguns són més savis, altres menys. Tothom és tractat igual. Bé, si l'usuari ignora les meves instruccions, disculpeu-me: l'ordre d'ignorar també s'introduirà per part meva.
És possible predir el desenvolupament dels sistemes de fitxers durant els propers cinc o deu anys? Quins creus que són els principals reptes que poden enfrontar els desenvolupadors de FS?
Sí, no és difícil fer una previsió així. Fa molt de temps que no hi ha cap desenvolupament de sistemes de fitxers a l'amunt. Només es crea l'aparença d'aquest. Els desenvolupadors de sistemes de fitxers locals van trobar problemes associats a un disseny deficient. Cal fer una advertència aquí. No considero que l'anomenat "emmagatzematge", "llepament" i portació de codi sigui desenvolupament i desenvolupament. I no classifico el malentès anomenat "Btrfs" com a desenvolupament per les raons que ja he explicat.
Cada pegat només empitjora els seus problemes. Bé. i sempre hi ha diversos tipus d'"evangelistes" per als quals "tot funciona". Bàsicament, es tracta d'escolars i estudiants que es salten conferències. Imagineu-vos: li funciona, però el professor no. Quina pujada d'adrenalina aquesta! Des del meu punt de vista, el dany més gran el causen els "artesans" que es van afanyar a "cargolar" amb entusiasme les meravelloses característiques de Btrfs a tot tipus de capes com systemd, docker, etc. - això ja s'assembla a metàstasis.
Ara intentem fer una previsió de cinc a deu anys. Ja he enumerat breument què farem a Reiser4. El principal repte per als desenvolupadors locals de FS des de l'aigües amunt serà (sí, ja s'ha convertit) la incapacitat de fer una feina digna per un sou. Sense cap idea en l'àmbit de l'emmagatzematge de dades, continuaran intentant pegar aquests desafortunats VFS, XFS i ext4. La situació amb VFS sembla especialment còmica en aquest context, que recorda la modernització frenètica d'un restaurant en el qual no hi ha xefs, ni s'espera cap xef.
Ara el codi VFS, sense cap condició, bloqueja diverses pàgines de memòria alhora i convida l'FS subjacent a operar-hi. Això es va introduir per millorar el rendiment d'Ext4 en operacions d'eliminació, però com és fàcil d'entendre, aquest bloqueig concurrent és completament incompatible amb els models de transaccions avançats. És a dir, no podreu simplement afegir suport per a algun sistema de fitxers intel·ligent al nucli. No sé quina és la situació en altres àrees de Linux, però pel que fa als sistemes de fitxers, és poc probable que cap desenvolupament aquí sigui compatible amb la política que segueix Torvalds a la pràctica (els projectes acadèmics són expulsats i els estafadors que no tinc ni idea de què s'emeten un arbre B, interminables crèdits de confiança). Per tant, es va establir un rumb per a la decadència lenta. Per descomptat, intentaran amb totes les seves forces fer-ho passar per "desenvolupament".
A més, els "custodis" dels sistemes de fitxers, adonant-se que no guanyareu gaire només amb l'"emmagatzematge", provaran la seva mà amb un negoci més rendible. Aquests són, per regla general, sistemes de fitxers distribuïts i virtualització. Potser portaran el ZFS de moda a un altre lloc on encara no existeix. Però, com tots els FS de aigües amunt, s'assembla a un arbre d'Any Nou: si podeu penjar algunes altres coses petites al damunt, no podreu aprofundir-hi més. Admeto que és possible construir un sistema empresarial seriós basat en ZFS, però com que ara estem discutint el futur, només puc afirmar amb tristesa que ZFS no té esperança en aquest sentit: amb els seus dispositius virtuals, els nois han tallat l'oxigen. per a ells mateixos i per a les generacions futures per al seu desenvolupament. ZFS és cosa del passat. I ext4 i XFS no ho són ni tan sols abans d'ahir.
Val la pena esmentar per separat el sensacional concepte de "sistema de fitxers Linux de nova generació". Aquest és un projecte completament polític i de màrqueting creat per tenir l'oportunitat, per dir-ho d'alguna manera, de "fixar el futur dels sistemes de fitxers" a Linux darrere de personatges específics. El fet és que Linux solia ser "només per diversió". Però ara és principalment una màquina de fer diners. Estan fets en tot el possible. Per exemple, és molt difícil crear un bon producte de programari, però els "desenvolupadors" intel·ligents s'han adonat des de fa temps que no cal esforçar-se gens: podeu vendre amb èxit programari inexistent que va ser anunciat i promocionat a tot tipus de públic. esdeveniments: el més important és que les diapositives de la presentació haurien de contenir més "funcions".
Els sistemes de fitxers són perfectes per a això, perquè podeu negociar amb seguretat durant deu anys sobre el resultat. Bé, si més tard algú es queixa de la manca d'aquest resultat, simplement no entén res dels sistemes de fitxers! Això recorda una piràmide financera: al capdamunt hi ha els aventurers que van iniciar aquest embolic, i aquells pocs que van tenir "sort": van "retirar dividends", és a dir. va rebre diners per al desenvolupament, va aconseguir una feina ben pagada com a gestors, es va "presentar" a conferències, etc.
A continuació, vindran els "desafortunats": comptaran les pèrdues, s'enfrontaran a les conseqüències de desplegar un producte de programari inutilitzable a la producció, "etc. N'hi ha molts més. Bé, a la base de la piràmide hi ha una gran massa de desenvolupadors que "seren" codi inútil. Són els grans perdedors, perquè el temps perdut no es pot tornar. Aquestes piràmides són extremadament beneficioses per a Torvalds i els seus associats. I com més d'aquestes piràmides, millor per a elles. Per alimentar aquestes piràmides, es pot portar qualsevol cosa al nucli. Això sí, en públic diuen el contrari. Però no jutjo per paraules sinó per accions.
Per tant, "el futur dels sistemes de fitxers a Linux" és un altre programari molt promocionat, però difícilment utilitzable. Després de Btrfs, amb una alta probabilitat, el lloc d'aquest "futur" serà ocupat per Bcachefs, que és un altre intent de creuar la capa de blocs de Linux amb un sistema de fitxers (un mal exemple és contagiós). I el que és típic: hi ha els mateixos problemes que en Btrfs. Vaig sospitar això durant molt de temps, i després d'alguna manera no vaig poder resistir-me i vaig mirar el codi: és cert!
Els autors de Bcachefs i Btrfs, quan van crear el seu FS, van utilitzar activament les fonts d'altres persones, entenent-ne poc. La situació recorda molt al joc dels nens "telèfon trencat". I em puc imaginar aproximadament com s'inclourà aquest codi al nucli. De fet, ningú veurà els "rastells" (tothom els trepitjarà més tard). Després de nombroses qüestions sobre l'estil del codi, acusacions de violacions inexistents, etc., es farà una conclusió sobre la "lleialtat" de l'autor, el bé que "interacciona" amb altres desenvolupadors i amb quina èxit pot tot això. després ser venut a corporacions.
El resultat final no interessarà a ningú. Fa vint anys, potser, m'hauria interessat, però ara les preguntes es plantegen d'una altra manera: serà possible potenciar-ho perquè en els propers deu anys s'ocupin determinades persones. I, per desgràcia, no és costum preguntar-se pel resultat final.
En general, desaconsellaria molt no començar a reinventar el vostre sistema de fitxers des de zero. Perquè fins i tot inversions financeres importants no seran suficients per aconseguir alguna cosa competitiva en deu anys. Per descomptat, parlo de projectes seriosos, i no d'aquells que es pretenen "empènyer" al nucli. Per tant, una manera més eficaç d'expressar-se és unir-se a desenvolupaments reals, com nosaltres. Això, per descomptat, no és fàcil de fer, però aquest és el cas de qualsevol projecte d'alt nivell.
En primer lloc, haureu de superar de manera independent el problema que us oferiré. Després d'això, convençut de la gravetat de les vostres intencions, començaré a ajudar. Tradicionalment, utilitzem només els nostres propis desenvolupaments. Les excepcions són els algorismes de compressió i algunes funcions hash. No enviem desenvolupadors a viatjar a conferències, i després no ens asseiem i combinem les idees d'altres persones ("potser què passarà"), com és habitual a la majoria de startups.
Desenvolupem tots els algorismes nosaltres mateixos. Actualment estic interessat en els aspectes algebraics i combinatoris de la ciència de l'emmagatzematge de dades. En particular, camps finits, asimptòtics, prova de desigualtats. També hi ha feina per als programadors normals, però us he d'avisar immediatament: s'ignoren tots els suggeriments per "mirar un altre FS i fer el mateix". També hi aniran els pedaços destinats a una integració més propera amb Linux mitjançant VFS.
Per tant, no tenim cap rasclet, però entenem cap a on ens hem de moure i tenim confiança que aquesta direcció és la correcta. Aquesta comprensió no va venir en forma de mannà del cel. Permeteu-me recordar-vos que tenim 29 anys d'experiència en desenvolupament a l'esquena, dos sistemes de fitxers escrits des de zero. I el mateix nombre d'utilitats de recuperació de dades. I això és molt!
Font: opennet.ru