Aquesta primavera ja hem tractat alguns temes introductoris, per exemple, и . En el segon d'ells, fins i tot ens vam comprometre a continuar estudiant el rendiment de diverses topologies multidisc a ZFS. Aquest és el sistema de fitxers de nova generació que ara s'està implementant a tot arreu: des до .
Bé, avui és el millor dia per familiaritzar-se amb ZFS, lectors curiosos. Només cal saber que, segons l'humil opinió del desenvolupador d'OpenZFS, Matt Ahrens, "és molt difícil".
Però abans d'arribar als números, i ho prometo, per a totes les opcions per a una configuració ZFS de vuit discs, hem de parlar de как En general, ZFS emmagatzema dades al disc.
Zpool, vdev i dispositiu
Aquest diagrama de conjunt complet inclou tres vdevs auxiliars, un de cada classe i quatre per a RAIDz2
Normalment no hi ha cap raó per crear un conjunt de tipus i mides de vdev no coincidents, però no hi ha res que us impedeix fer-ho si voleu.
Per entendre realment el sistema de fitxers ZFS, heu de fer una ullada a la seva estructura real. En primer lloc, ZFS unifica els nivells tradicionals de gestió del volum i del sistema de fitxers. En segon lloc, utilitza un mecanisme transaccional de còpia sobre escriptura. Aquestes característiques signifiquen que el sistema és estructuralment molt diferent dels sistemes de fitxers convencionals i les matrius RAID. El primer conjunt de blocs bàsics que cal entendre són l'agrupació d'emmagatzematge (zpool), el dispositiu virtual (vdev) i el dispositiu real (dispositiu).
zpool
L'agrupació d'emmagatzematge zpool és l'estructura ZFS més alta. Cada grup conté un o més dispositius virtuals. Al seu torn, cadascun d'ells conté un o més dispositius reals (dispositiu). Les piscines virtuals són blocs autònoms. Un ordinador físic pot contenir dos o més grups separats, però cadascun és completament independent dels altres. Els grups no poden compartir dispositius virtuals.
La redundància de ZFS és a nivell de dispositiu virtual, no a nivell de grup. No hi ha absolutament cap redundància al nivell de l'agrupació: si es perd algun vdev d'unitat o vdev especial, es perd tot el grup juntament amb ell.
Les agrupacions d'emmagatzematge modernes poden sobreviure a la pèrdua d'una memòria cau o registre de dispositiu virtual, tot i que poden perdre una petita quantitat de dades brutes si perden el registre vdev durant una interrupció de l'alimentació o un error del sistema.
Hi ha una idea errònia comú que les "bandes de dades" de ZFS s'escriuen a tot el grup. Això no és cert. Zpool no és gens divertit RAID0, és bastant divertit amb un complex mecanisme de distribució variable.
En la seva major part, els registres es distribueixen entre els dispositius virtuals disponibles segons l'espai lliure disponible, de manera que en teoria s'ompliran tots alhora. A les versions posteriors de ZFS, es té en compte l'ús (utilització) actual del vdev: si un dispositiu virtual està significativament més ocupat que un altre (per exemple, a causa de la càrrega de lectura), s'ometrà temporalment per escriure, tot i tenir la màxima gratuïtat. relació d'espai.
El mecanisme de detecció d'utilització integrat als mètodes d'assignació d'escriptura ZFS moderns pot reduir la latència i augmentar el rendiment durant períodes de càrrega inusualment alta, però no és així. carta blanca sobre la barreja involuntària de discs durs lents i SSD ràpids en un sol grup. Un grup tan desigual encara funcionarà a la velocitat del dispositiu més lent, és a dir, com si estigués totalment compost per aquests dispositius.
vdev
Cada agrupació d'emmagatzematge consta d'un o més dispositius virtuals (dispositiu virtual, vdev). Al seu torn, cada vdev conté un o més dispositius reals. La majoria de dispositius virtuals s'utilitzen per emmagatzemar dades senzilles, però hi ha diverses classes d'ajuda de vdev, com ara CACHE, LOG i SPECIAL. Cadascun d'aquests tipus de vdev pot tenir una de les cinc topologies: dispositiu únic (dispositiu únic), RAIDz1, RAIDz2, RAIDz3 o mirall (mirall).
RAIDz1, RAIDz2 i RAIDz3 són varietats especials del que els antics anomenarien RAID de paritat doble (diagonal). 1, 2 i 3 fan referència a quants blocs de paritat s'assignen per a cada banda de dades. En lloc de discs separats per a la paritat, els dispositius virtuals RAIDz distribueixen aquesta paritat de manera semiigual entre els discos. Una matriu RAIDz pot perdre tants discs com blocs de paritat té; si en perd un altre, es bloquejarà i s'emportarà el grup d'emmagatzematge.
En dispositius virtuals reflectits (mirall vdev), cada bloc s'emmagatzema a cada dispositiu del vdev. Tot i que els miralls de dos amples són els més comuns, qualsevol nombre arbitrari de dispositius pot estar en un mirall; sovint s'utilitzen triples en grans instal·lacions per millorar el rendiment de lectura i la tolerància a errors. Un mirall de vdev pot sobreviure a qualsevol fallada sempre que almenys un dispositiu del vdev continuï funcionant.
Els vdevs únics són intrínsecament perillosos. Aquest dispositiu virtual no sobreviurà a una sola fallada, i si s'utilitza com a emmagatzematge o un vdev especial, la seva fallada provocarà la destrucció de tota la piscina. Sigueu molt, molt atents aquí.
Les VA CACHE, LOG i ESPECIALS es poden crear utilitzant qualsevol de les topologies anteriors, però recordeu que la pèrdua d'una VA ESPECIAL significa la pèrdua de l'agrupació, per la qual cosa es recomana una topologia redundant.
dispositiu
Aquest és probablement el terme més fàcil d'entendre a ZFS: és literalment un dispositiu d'accés aleatori de blocs. Recordeu que els dispositius virtuals estan formats per dispositius individuals, mentre que un grup està format per dispositius virtuals.
Els discos, ja siguin magnètics o d'estat sòlid, són els dispositius de blocs més comuns que s'utilitzen com a blocs de construcció de vdev. Tanmateix, qualsevol dispositiu amb un descriptor a /dev ho farà, de manera que les matrius RAID de maquinari senceres es poden utilitzar com a dispositius separats.
Un fitxer en brut simple és un dels dispositius de bloc alternatius més importants a partir dels quals es pot crear un vdev. Piscinas de prova de és una manera molt útil de comprovar les ordres de l'agrupació i veure quant d'espai hi ha disponible en un grup o dispositiu virtual d'una topologia determinada.
Podeu crear un grup de proves a partir de fitxers escassos en pocs segons, però no us oblideu de suprimir tot el grup i els seus components després
Suposem que voleu posar un servidor en vuit discos i teniu previst utilitzar discs de 10 TB (~9300 GiB), però no esteu segurs de quina topologia s'adapta millor a les vostres necessitats. A l'exemple anterior, creem un grup de proves a partir de fitxers escassos en segons, i ara sabem que un vdev RAIDz2 de vuit discos de 10 TB proporciona 50 TiB de capacitat útil.
Una altra classe especial de dispositius és SPARE (recanvi). Els dispositius d'intercanvi en calent, a diferència dels dispositius normals, pertanyen a tot el grup i no a un sol dispositiu virtual. Si un vdev de l'agrupació falla i un dispositiu de recanvi està connectat a l'agrupació i està disponible, s'unirà automàticament al vdev afectat.
Després de connectar-se al vdev afectat, el dispositiu de recanvi comença a rebre còpies o reconstruccions de les dades que haurien d'estar al dispositiu que falta. En el RAID tradicional això s'anomena reconstrucció, mentre que en ZFS s'anomena resilvering.
És important tenir en compte que els dispositius de recanvi no substitueixen permanentment els dispositius fallits. Això només és un reemplaçament temporal per reduir la quantitat de temps que es degrada vdev. Després que l'administrador substitueixi el vdev fallit, la redundància es restaura a aquest dispositiu permanent i el REPARAT es desconnecta del vdev i es torna a funcionar com a recanvi per a tot el grup.
Conjunts de dades, blocs i sectors
El següent conjunt de blocs de construcció per entendre en el nostre viatge ZFS és menys sobre el maquinari i més sobre com s'organitzen i s'emmagatzemen les dades. Ens ometem alguns nivells aquí, com ara metaslab, per no desordenar els detalls tot mantenint una comprensió de l'estructura general.
Conjunt de dades (conjunt de dades)
Quan creem per primera vegada un conjunt de dades, mostra tot l'espai de la piscina disponible. A continuació, establim la quota i canviem el punt de muntatge. Màgia!
Zvol és en la seva major part només un conjunt de dades despullat de la seva capa de sistema de fitxers, que estem substituint aquí per un sistema de fitxers ext4 perfectament normal.
Un conjunt de dades ZFS és aproximadament el mateix que un sistema de fitxers muntat estàndard. Com un sistema de fitxers normal, a primera vista sembla "només una carpeta més". Però igual que els sistemes de fitxers muntables habituals, cada conjunt de dades ZFS té el seu propi conjunt de propietats bàsiques.
En primer lloc, un conjunt de dades pot tenir una quota assignada. Si s'estableix zfs set quota=100G poolname/datasetname, aleshores no podreu escriure a la carpeta muntada /poolname/datasetname més de 100 GiB.
Observeu la presència -i l'absència- de barres inclinades al començament de cada línia? Cada conjunt de dades té el seu propi lloc tant a la jerarquia ZFS com a la jerarquia de muntatge del sistema. No hi ha cap barra inclinada inicial a la jerarquia ZFS: comenceu amb el nom del grup i després el camí d'un conjunt de dades al següent. Per exemple, pool/parent/child per a un conjunt de dades anomenat child sota el conjunt de dades principal parent en una piscina amb un nom creatiu pool.
De manera predeterminada, el punt de muntatge del conjunt de dades serà equivalent al seu nom a la jerarquia ZFS, amb una barra inclinada inicial: el grup anomenat pool muntat com /pool, conjunt de dades parent muntat dins /pool/parent, i el conjunt de dades fill child muntat dins /pool/parent/child. Tanmateix, el punt de muntatge del sistema del conjunt de dades es pot canviar.
Si ho especifiquem zfs set mountpoint=/lol pool/parent/child, després el conjunt de dades pool/parent/child muntat al sistema com /lol.
A més dels conjunts de dades, hem d'esmentar els volums (zvols). Un volum és aproximadament el mateix que un conjunt de dades, excepte que en realitat no té un sistema de fitxers: només és un dispositiu de bloc. Podeu, per exemple, crear zvol Amb nom mypool/myzvol, després formateu-lo amb un sistema de fitxers ext4 i després munteu aquest sistema de fitxers; ara teniu un sistema de fitxers ext4, però amb totes les característiques de seguretat de ZFS! Això pot semblar una tonteria en una sola màquina, però té molt més sentit com a backend quan exporteu un dispositiu iSCSI.
Blocs
El fitxer està representat per un o més blocs. Cada bloc s'emmagatzema en un dispositiu virtual. La mida del bloc sol ser igual al paràmetre mida del registre, però es pot reduir a 2^canvisi conté metadades o un fitxer petit.
Nosaltres realment de veritat no fer broma sobre l'enorme penalització de rendiment si estableixes un canvi massa petit
En un grup ZFS, totes les dades, incloses les metadades, s'emmagatzemen en blocs. La mida màxima de bloc per a cada conjunt de dades es defineix a la propietat recordsize (mida del registre). La mida del registre es pot canviar, però això no canviarà la mida ni la ubicació de cap bloc que ja s'hagi escrit al conjunt de dades; només afecta els blocs nous a mesura que s'escriuen.
Tret que s'especifiqui el contrari, la mida del registre per defecte actual és de 128 KiB. És una mena de compensació complicada on el rendiment no és perfecte, però tampoc és terrible en la majoria dels casos. Recordsize es pot configurar amb qualsevol valor des de 4K fins a 1M (amb configuracions avançades recordsize podeu instal·lar-ne encara més, però poques vegades és una bona idea).
Qualsevol bloc es refereix a les dades d'un sol fitxer; no podeu agrupar dos fitxers diferents en un sol bloc. Cada fitxer consta d'un o més blocs, segons la mida. Si la mida del fitxer és més petita que la mida del registre, s'emmagatzemarà en una mida de bloc més petita; per exemple, un bloc amb un fitxer de 2 KiB ocuparà només un sector de 4 KiB al disc.
Si el fitxer és prou gran i requereix diversos blocs, tots els registres amb aquest fitxer seran de mida recordsize - inclosa l'última entrada, la part principal de la qual pot ser .
Els zvols no tenen propietat recordsize — en canvi tenen una propietat equivalent volblocksize.
Sectors
L'últim bloc de construcció més bàsic és el sector. És la unitat física més petita que es pot escriure o llegir des del dispositiu subjacent. Durant diverses dècades, la majoria dels discs van utilitzar sectors de 512 bytes. Recentment, la majoria dels discos estan configurats en sectors de 4 KiB i alguns, especialment els SSD, tenen sectors de 8 KiB o fins i tot més.
El sistema ZFS té una propietat que us permet configurar manualment la mida del sector. Aquesta propietat ashift. Una mica confús, el canvi és un poder de dos. Per exemple, ashift=9 significa una mida del sector de 2^9, o 512 bytes.
ZFS consulta el sistema operatiu per obtenir informació detallada sobre cada dispositiu de bloc quan s'afegeix a un nou vdev i, teòricament, instal·la automàticament ashift correctament en funció d'aquesta informació. Malauradament, moltes unitats es troben sobre la mida del seu sector per tal de mantenir la compatibilitat amb Windows XP (que no va poder entendre les unitats amb altres mides de sector).
Això vol dir que es recomana encaridament a un administrador de ZFS que conegui la mida real del sector dels seus dispositius i que la configuren manualment. ashift. Si l'ashift s'estableix massa baix, el nombre d'operacions de lectura/escriptura augmenta astronòmicament. Així, escriure "sectors" de 512 bytes en un sector real de 4 KiB significa haver d'escriure el primer "sector", després llegir el sector de 4 KiB, modificar-lo amb un segon "sector de 512 bytes", escriure'l de nou al nou. 4 sectors de KiB, etc. per a cada entrada.
Al món real, aquesta penalització afecta els SSD EVO de Samsung, per la qual cosa ashift=13, però aquests SSD es troben sobre la mida del seu sector i, per tant, el valor predeterminat està establert a ashift=9. Si un administrador del sistema experimentat no canvia aquesta configuració, aquest SSD funciona més lent HDD magnètic convencional.
Per comparació, per a una mida massa gran ashift pràcticament no hi ha penalització. No hi ha cap penalització de rendiment real i l'augment de l'espai no utilitzat és infinitesimal (o zero amb la compressió activada). Per tant, recomanem fermament que s'instal·lin fins i tot aquelles unitats que utilitzen sectors de 512 bytes ashift=12 o ashift=13per afrontar el futur amb confiança.
Propietat ashift s'estableix per a cada dispositiu virtual vdev, i no per la piscina, com molts pensen erròniament, i no canvia després de la instal·lació. Si pegues accidentalment ashift quan afegiu un nou vdev a una piscina, heu contaminat irremeiablement aquesta piscina amb un dispositiu de baix rendiment i normalment no hi ha cap altra opció que destruir la piscina i començar de nou. Fins i tot eliminar vdev no us salvarà d'una configuració trencada ashift!
Mecanisme de còpia sobre escriptura
Si un sistema de fitxers normal necessita sobreescriure dades, canvia cada bloc on es troba
Un sistema de fitxers de còpia sobre escriptura escriu una versió de bloc nova i després desbloqueja la versió antiga
En resum, si ignorem la ubicació física real dels blocs, aleshores el nostre "cometa de dades" es simplifica a un "cuc de dades" que es mou d'esquerra a dreta pel mapa de l'espai disponible.
Ara podem fer-nos una bona idea de com funcionen les instantànies de còpia en escriptura: cada bloc pot pertànyer a diverses instantànies i persistirà fins que es destrueixin totes les instantànies associades.
El mecanisme Copy on Write (CoW) és la base fonamental del que fa que ZFS sigui un sistema tan sorprenent. El concepte bàsic és senzill: si demaneu a un sistema de fitxers tradicional que canviï un fitxer, farà exactament el que heu demanat. Si demaneu a un sistema de fitxers de còpia sobre escriptura que faci el mateix, us dirà "d'acord", però us mentirà.
En canvi, un sistema de fitxers de còpia sobre escriptura escriu una nova versió del bloc modificat i després actualitza les metadades del fitxer per desenllaçar el bloc antic i associar-hi el bloc nou que acabeu d'escriure.
Desconnectar el bloc antic i enllaçar-ne el nou es fa en una sola operació, de manera que no es pot interrompre: si apagueu el bloc després que això passi, teniu una versió nova del fitxer i, si s'apaga abans, teniu la versió antiga. . En qualsevol cas, no hi haurà conflictes en el sistema de fitxers.
La còpia sobre escriptura a ZFS no només es produeix al nivell del sistema de fitxers, sinó també al nivell de gestió del disc. Això vol dir que ZFS no es veu afectat pels espais en blanc () - un fenomen quan la tira va tenir temps de gravar només parcialment abans que el sistema s'estavellés, amb danys a la matriu després d'un reinici. Aquí la ratlla s'escriu atòmicament, vdev sempre és seqüencial i .
ZIL: registre d'intencions de ZFS
El sistema ZFS tracta les escriptures síncrones d'una manera especial: les emmagatzema temporalment però immediatament a ZIL abans d'escriure-les permanentment més tard juntament amb les escriptures asíncrones.
Normalment, les dades escrites en un ZIL mai es tornen a llegir. Però és possible després d'un error del sistema
SLOG, o dispositiu LOG secundari, és només un vdev especial, i preferiblement molt ràpid, on el ZIL es pot emmagatzemar per separat de l'emmagatzematge principal.
Després d'un error, es reprodueixen totes les dades brutes de ZIL; en aquest cas, ZIL està a SLOG, de manera que es reprodueix des d'allà.
Hi ha dues categories principals d'operacions d'escriptura: síncrones (sincronitzades) i asíncrones (asíncrones). Per a la majoria de les càrregues de treball, la gran majoria de les escriptures són asíncrones: el sistema de fitxers permet agregar-les i publicar-les per lots, reduint la fragmentació i augmentant molt el rendiment.
Les gravacions sincronitzades són una qüestió completament diferent. Quan una aplicació demana una escriptura síncrona, diu al sistema de fitxers: "Heu de confirmar-ho a la memòria no volàtil. ara mateixfins aleshores, no puc fer res més". Per tant, les escriptures sincròniques s'han de comprometre immediatament al disc, i si això augmenta la fragmentació o redueix el rendiment, així sigui.
ZFS gestiona les escriptures sincròniques de manera diferent que els sistemes de fitxers normals; en lloc de comprometre-les immediatament a l'emmagatzematge normal, ZFS les envia a una àrea d'emmagatzematge especial anomenada ZFS Intent Log o ZIL. El truc és que aquests registres també romanen a la memòria, s'agreguen juntament amb les sol·licituds d'escriptura asíncrona normals, per ser enviades posteriorment a l'emmagatzematge com a TXG (grups de transaccions) perfectament normals.
En funcionament normal, el ZIL s'escriu i no es torna a llegir mai més. Quan, al cap d'uns moments, els registres del ZIL es comprometen a l'emmagatzematge principal en TXG normals de la memòria RAM, es desconnecten del ZIL. L'única vegada que es llegeix alguna cosa del ZIL és quan s'importa el grup.
Si falla ZFS (un error del sistema operatiu o un tall d'alimentació) mentre hi ha dades al ZIL, aquestes dades es llegiran durant la propera importació del grup (per exemple, quan es reiniciï el sistema d'emergència). Qualsevol cosa del ZIL es llegirà, s'agruparà en TXG, es comprometrà a l'emmagatzematge principal i, a continuació, es desconnectarà del ZIL durant el procés d'importació.
Una de les classes d'ajuda de vdev s'anomena LOG o SLOG, el dispositiu secundari de LOG. Té un objectiu: proporcionar al grup un vdev separat, i preferiblement molt més ràpid, molt resistent a l'escriptura per emmagatzemar el ZIL, en lloc d'emmagatzemar el ZIL a la botiga principal de vdev. El mateix ZIL es comporta igual sense importar on estigui emmagatzemat, però si el LOG vdev té un rendiment d'escriptura molt alt, les escriptures sincròniques seran més ràpides.
Afegir un vdev amb LOG al grup no funciona no pot milloreu el rendiment d'escriptura asíncrona, fins i tot si forceu totes les escriptures a ZIL amb zfs set sync=always, encara estaran vinculats a l'emmagatzematge principal a TXG de la mateixa manera i al mateix ritme que sense el registre. L'única millora directa del rendiment és la latència de les escriptures sincròniques (perquè un registre més ràpid accelera les operacions). sync).
Tanmateix, en un entorn que ja requereix moltes escriptures sincròniques, vdev LOG pot accelerar indirectament les escriptures asíncrones i les lectures no emmagatzemades en memòria cau. La descàrrega d'entrades ZIL a un Registre de vdev independent significa menys contenció per IOPS a l'emmagatzematge principal, cosa que millora el rendiment de totes les lectures i escriptures fins a cert punt.
Imatges instantànies
El mecanisme de còpia sobre escriptura també és una base necessària per a les instantànies atòmiques de ZFS i la replicació asíncrona incremental. El sistema de fitxers actiu té un arbre de punters que marca tots els registres amb les dades actuals; quan feu una instantània, simplement feu una còpia d'aquest arbre de punters.
Quan un registre es sobreescriu al sistema de fitxers actiu, ZFS escriu primer la nova versió del bloc a l'espai no utilitzat. Aleshores, separa la versió antiga del bloc del sistema de fitxers actual. Però si alguna instantània es refereix al bloc antic, encara roman sense canvis. El bloc antic no es restaurarà com a espai lliure fins que es destrueixin totes les instantànies que fan referència a aquest bloc!
replicació
La meva biblioteca de Steam el 2015 era de 158 GiB i incloïa 126 fitxers. Això està força a prop de la situació òptima per a rsync: la replicació de ZFS a la xarxa va ser "només" un 927% més ràpida.
A la mateixa xarxa, replicar un únic fitxer d'imatge de màquina virtual Windows 40 de 7 GB és una història completament diferent. La rèplica ZFS és 289 vegades més ràpida que rsync, o "només" 161 vegades més ràpid si sou prou intel·ligent com per trucar a rsync amb --inplace.
Quan s'escala una imatge de VM, els problemes de rsync s'escalen amb ella. 1,9 TiB no és tan gran per a una imatge de VM moderna, però és prou gran perquè la replicació ZFS sigui 1148 vegades més ràpida que rsync, fins i tot amb l'argument --inplace de rsync
Un cop hàgiu entès com funcionen les instantànies, hauria de ser fàcil comprendre l'essència de la replicació. Com que una instantània és només un arbre de punters a registres, es dedueix que si ho fem zfs send instantània, llavors enviem tant aquest arbre com tots els registres associats amb ell. Quan enviem això zfs send в zfs receive a l'objectiu, escriu tant el contingut real del bloc com l'arbre de punters que fan referència als blocs al conjunt de dades de destinació.
Les coses es tornen encara més interessants al segon zfs send. Ara tenim dos sistemes, cadascun conté poolname/datasetname@1, i fas una nova instantània poolname/datasetname@2. Per tant, a la piscina original tens datasetname@1 и datasetname@2, i al grup objectiu fins ara només la primera instantània datasetname@1.
Com que tenim una instantània comuna entre la font i l'objectiu datasetname@1, podem fer-ho incremental zfs send per damunt de. Quan diem al sistema zfs send -i poolname/datasetname@1 poolname/datasetname@2, compara dos arbres de punters. Qualsevol punter que només existeix en @2, òbviament es refereixen a blocs nous; per tant, necessitem el contingut d'aquests blocs.
En un sistema remot, processant un incremental send igual de simple. Primer escrivim totes les entrades noves incloses al flux send, i després afegiu punters a aquests blocs. Voila, tenim @2 al nou sistema!
La replicació incremental asíncrona de ZFS és una gran millora respecte a mètodes anteriors no basats en instantànies, com ara rsync. En ambdós casos, només es transfereixen les dades modificades, però primer ha de ser rsync llegir del disc totes les dades d'ambdós costats per comprovar la suma i comparar-la. En canvi, la replicació ZFS no llegeix més que arbres de punters, i qualsevol bloc que no estigui present a la instantània compartida.
Compressió incorporada
El mecanisme de còpia sobre escriptura també simplifica el sistema de compressió en línia. En un sistema de fitxers tradicional, la compressió és problemàtica: tant la versió antiga com la nova de les dades modificades resideixen al mateix espai.
Si considerem una dada al mig d'un fitxer que comença la vida com un megabyte de zeros a partir de 0x00000000 i així successivament, és molt fàcil comprimir-lo a un sector del disc. Però, què passa si substituïm aquest megabyte de zeros per un megabyte de dades incompressibles com JPEG o soroll pseudoaleatori? Inesperadament, aquest megabyte de dades requerirà no un, sinó 256 sectors de 4 KiB, i en aquest lloc del disc només hi ha un sector reservat.
ZFS no té aquest problema, ja que els registres modificats sempre s'escriuen a l'espai no utilitzat: el bloc original només ocupa un sector de 4 KiB i el nou registre n'ocuparà 256, però això no és un problema: un fragment modificat recentment del " central" del fitxer s'escriuria a l'espai no utilitzat, independentment de si la seva mida ha canviat o no, de manera que per a ZFS aquesta és una situació bastant normal.
La compressió ZFS nativa està desactivada de manera predeterminada i el sistema ofereix algorismes connectables, actualment LZ4, gzip (1-9), LZJB i ZLE.
- LZ4 és un algorisme de transmissió que ofereix una compressió i descompressió extremadament ràpides i avantatges de rendiment per a la majoria dels casos d'ús, fins i tot en CPU bastant lentes.
- GZIP és un algorisme venerable que tots els usuaris d'Unix coneixen i estimen. Es pot implementar amb els nivells de compressió 1-9, amb la proporció de compressió i l'ús de la CPU augmentant a mesura que s'acosta al nivell 9. L'algoritme és adequat per a tots els casos d'ús de text (o altres casos d'ús altament compressibles), però d'altra manera sovint causa problemes de CPU; amb cura, sobretot a nivells superiors.
- LZJB és l'algoritme original de ZFS. Està obsolet i ja no s'ha d'utilitzar, el LZ4 el supera en tots els sentits.
- ZLE - codificació de nivell zero, codificació de nivell zero. No toca gens les dades normals, però comprimeix grans seqüències de zeros. Útil per a conjunts de dades completament incompressibles (com ara JPEG, MP4 o altres formats ja comprimits), ja que ignora les dades incompressibles però comprimeix l'espai no utilitzat als registres resultants.
Recomanem la compressió LZ4 per a gairebé tots els casos d'ús; la penalització de rendiment quan es troben dades incompressibles és molt petita, i creixement El rendiment de les dades típiques és important. Còpia d'una imatge de màquina virtual per a una nova instal·lació del sistema operatiu Windows (SO recentment instal·lat, encara no hi ha dades) amb compression=lz4 va passar un 27% més ràpid que amb compression=nonea .
ARC: memòria cau de substitució adaptativa
ZFS és l'únic sistema de fitxers modern que coneixem que utilitza el seu propi mecanisme de memòria cau de lectura, en lloc de confiar en la memòria cau de pàgines del sistema operatiu per emmagatzemar còpies dels blocs llegits recentment a la memòria RAM.
Tot i que la memòria cau nativa no està exempta de problemes, ZFS no pot respondre a les noves sol·licituds d'assignació de memòria tan ràpidament com el nucli, per tant, el nou repte malloc() en l'assignació de memòria pot fallar si necessita la memòria RAM que ocupa actualment l'ARC. Però hi ha bones raons per utilitzar la vostra pròpia memòria cau, almenys de moment.
Tots els sistemes operatius moderns coneguts, inclosos MacOS, Windows, Linux i BSD, utilitzen l'algoritme LRU (Least Recently Used) per implementar la memòria cau de la pàgina. Aquest és un algorisme primitiu que empeny el bloc de la memòria cau "amunt de la cua" després de cada lectura, i empeny els blocs "avall de la cua" segons sigui necessari per afegir nous errors de memòria cau (blocs que s'haurien d'haver llegit des del disc, no des de la memòria cau) amunt.
L'algoritme acostuma a funcionar bé, però en sistemes amb grans conjunts de dades de treball, LRU condueix fàcilment a la batuda: desallotja els blocs que es necessiten amb freqüència per deixar espai als blocs que mai més es llegiran de la memòria cau.
és un algorisme molt menys ingenu que es pot considerar com una memòria cau "ponderada". Cada vegada que es llegeix un bloc a la memòria cau, es fa una mica més "pesat" i més difícil de desallotjar, i fins i tot després de desallotjar un bloc rastrejat en un període de temps determinat. Un bloc que s'ha desallotjat però que s'ha de llegir de nou a la memòria cau també es farà "més pesat".
El resultat final de tot això és una memòria cau amb una proporció d'èxits molt més alta, la proporció entre les visites de memòria cau (lectures realitzades des de la memòria cau) i les falles de la memòria cau (lleccions del disc). Aquesta és una estadística extremadament important: no només les visites de la memòria cau en si mateixes s'expliquen ordres de magnitud més ràpidament, sinó que les falles de memòria cau també es poden servir més ràpidament, ja que com més visites de memòria cau hi hagi, menys sol·licituds de disc concurrents i menor serà la latència d'aquelles errades restants. que s'ha de servir amb disc.
Conclusió
Després d'aprendre la semàntica bàsica de ZFS (com funciona la còpia sobre escriptura, així com les relacions entre grups d'emmagatzematge, dispositius virtuals, blocs, sectors i fitxers), estem preparats per parlar del rendiment del món real amb números reals.
A la següent part, farem una ullada al rendiment real de les agrupacions amb vdevs reflectits i RAIDz, entre si, i també en comparació amb les topologies RAID tradicionals del nucli de Linux que hem explorat. .
Al principi, volíem cobrir només els conceptes bàsics, les topologies ZFS, però després tal preparem-nos per parlar de la configuració i l'ajustament més avançats de ZFS, inclòs l'ús de tipus de vdev auxiliars com L2ARC, SLOG i l'assignació especial.
Font: www.habr.com