Sta primavera avemu digià discututu qualchi sughjetti introduttori, p.e. и . In u sicondu di questi, avemu ancu prumessu di cuntinuà à studià u funziunamentu di diverse topologies multi-dischi in ZFS. Questu hè u sistema di fugliali di a prossima generazione chì hè avà implementatu in ogni locu à .
Ebbè, oghje hè u megliu ghjornu per cunnosce ZFS, lettori curiosi. Sapete chì in l'umile valutazione di u sviluppatore OpenZFS Matt Ahrens, "hè veramente difficiule".
Ma prima di ghjunghje à i numeri - è ci sarà, prumessu - per tutte e varianti di a cunfigurazione ZFS di ottu discu, avemu bisognu di parlà. quantu In generale, ZFS guarda dati nantu à u discu.
Zpool, vdev è dispusitivu
Stu schema di piscina completa include trè vdevs ausiliari, unu di ogni classa, è quattru per RAIDz2
Di solitu ùn ci hè nisuna ragione per creà una piscina di tippi è dimensioni vdev incompatibili - ma se vulete, ùn ci hè nunda chì vi impedisce di fà.
Per capisce veramente u sistema di schedari ZFS, avete bisognu à fighjà attente à a so struttura attuale. Prima, ZFS unifica u voluminu tradiziunale è i strati di gestione di u sistema di fugliale. Siconda, usa un mecanismu transazionale di copia nantu à scrittura. Queste caratteristiche significanu chì u sistema hè strutturalmente assai sfarente da i sistemi di schedarii cunvinziunali è l'array RAID. U primu settore di blocchi di custruzzione di basa per capiscenu sò a piscina di almacenamiento (zpool), u dispositivu virtuale (vdev) è u dispusitivu reale (dispositivu).
zpool
U pool di almacenamiento zpool hè a struttura ZFS più alta. Ogni piscina cuntene unu o più dispositi virtuali. In turnu, ognunu di li cuntene unu o più veri dispusitivi (dispositivi). Piscine virtuale sò unità autonome. Un urdinatore fisicu pò cuntene duie o più piscine separate, ma ognuna hè completamente indipendente di l'altri. Piscine ùn ponu sparte dispusitivi virtuale.
A redundanza ZFS hè à u livellu di u dispositivu virtuale, micca à u livellu di u pool. Ùn ci hè assolutamente micca redundanza à u livellu di a piscina - se un vdev o un vdev dedicatu hè persu, a piscina sana hè persa cun ellu.
I pools di almacenamentu muderni ponu sopravvive à a perdita di a cache o di u log di un dispositivu virtuale - ancu s'ellu pò perde una piccula quantità di dati sporchi se perde u log vdev durante una mancanza di energia o un crash di u sistema.
Ci hè un misconception cumuni chì ZFS "strisce di dati" sò scritti in tutta a piscina. Questu hè micca veru. Zpool ùn hè micca un RAID0 divertente, hè più divertente cù un cumplessu mecanismu di distribuzione variabile.
Per a maiò parte, i registri sò distribuiti trà i dispositi virtuali dispunibuli secondu u spaziu liberu dispunibule, cusì in teoria seranu tutti pieni à u stessu tempu. E versioni più recenti di ZFS piglianu in contu l'usu vdev attuale (disposizione) - se un dispositivu virtuale hè significativamente più occupatu di l'altru (per esempiu, per via di a carica di lettura), serà saltatu temporaneamente per scrive, malgradu avè u più altu rapportu di spaziu liberu. .
U mecanismu di rilevazione di riciclamentu integratu in i metudi muderni di allocazione di scrittura ZFS pò riduce a latenza è aumentà u throughput durante i periodi di carica inusualmente alta - ma ùn hè micca. carta bianca à un mischju involuntariu di HDD lenti è SSD veloci in un pool. Un tali piscina ineguale hà sempre upirari à a vitezza di u dispusitivu più lentu, vale à dì, cum'è s'ellu era sanu cumpostu di tali dispusitivi.
vdev
Ogni pool di almacenamiento hè custituitu da unu o più dispositi virtuali (vdev). À u turnu, ogni vdev include unu o più dispositi reali. A maiò parte di i dispositi virtuali sò usati per un almacenamentu simplice di dati, ma ci sò parechje classi d'aiutu di vdev, cumprese CACHE, LOG, è SPECIAL. Ognunu di sti tipi di vdev pò avè una di cinque topologies: unicu dispositivu, RAIDz1, RAIDz2, RAIDz3 o mirror.
RAIDz1, RAIDz2 è RAIDz3 sò varietà speciale di ciò chì i vechji chjamanu RAID parità doppia (diagonale). 1, 2 è 3 si riferiscenu à quanti blocchi di parità sò attribuiti à ogni corsia di dati. Invece di avè dischi separati per furnisce a parità, i dispositi virtuali RAIDz distribuiscenu a parità semi-uniforme in i dischi. Un array RAIDz pò perde quant'è dischi quant'ellu hà blocchi di parità; s'ellu perde un altru, fallirà è piglià a piscina di almacenamiento cun ella.
In i dispositi virtuali specchiu (mirror vdev), ogni bloccu hè almacenatu in ogni dispusitivu in u vdev. Ancu s'è i specchi di dui largu sò i più cumuni, un specchiu pò cuntene un numeru arbitrariu di dispusitivi - in grandi installazioni, i tripli sò spessu usati per migliurà a prestazione di lettura è a toleranza di difetti. Un specchiu vdev pò sopravvive à qualsiasi fallimentu, sempre chì almenu un dispositivu in u vdev resta operativu.
I vdev unichi sò intrinsecamente periculosi. Un tali dispositivu virtuale ùn sopravvive micca un solu fallimentu - è s'ellu s'utilice cum'è almacenamiento o un vdev speciale, u so fallimentu porta à a distruzzione di tutta a piscina. Siate assai, assai attenti quì.
I dispusitivi virtuali CACHE, LOG, è SPECIAL ponu esse creati in ogni topulugia sopra - ma ricordate chì perda un dispositivu virtuale SPECIAL significa perde a piscina, cusì una topulugia redundante hè assai cunsigliata.
aparechju
Questu hè probabilmente u terminu più faciule da capisce in ZFS - hè literalmente un dispositivu di accessu aleatoriu di bloccu. Ricurdativi chì i dispositi virtuali sò custituiti da i dispositi individuali, è una piscina hè fatta di i dispositi virtuali.
I dischi, sia magnetici sia stati solidi, sò i dispositi di bloccu più cumuni utilizati cum'è blocchi di costruzione di vdev. Tuttavia, qualsiasi dispositivu cù un descrittore in / dev farà - cusì l'array RAID hardware tutale pò esse usatu cum'è dispositi separati.
Un schedariu raw simplice hè unu di i dispositi di bloccu alternativu più impurtanti da quale un vdev pò esse custruitu. Test piscine da hè un modu assai cunvene per verificà i cumandamenti di piscina è vede quantu spaziu hè dispunibule in una piscina o un dispositivu virtuale di una topulugia data.
Pudete creà un pool di teste da i fugliali sparsi in pocu seconde - ma ùn vi scurdate di sguassà tuttu u pool è i so cumpunenti dopu.
Diciamu chì vulete un servitore di ottu dischi è pensa à utilizà dischi 10 TB (~ 9300 GiB) - ma ùn sapete micca chì topologia si adatta più à i vostri bisogni. In l'esempiu sopra, custruemu un gruppu di teste da i schedari sparse in una materia di sicondi - è avà sapemu chì un RAIDz2 vdev di ottu dischi 10 TB furnisce 50 TiB di capacità utilizable.
Una altra classa speciale di dispusitivi hè SPARE. I dispusitivi hot-swap, à u cuntrariu di i dispositi regulari, appartenenu à a piscina sana piuttostu cà à un solu dispositivu virtuale. Se qualsiasi vdev in a piscina falla è un dispositivu spare hè cunnessu à a piscina è dispunibule, allora si unisce automaticamente à u vdev affettatu.
Una volta cunnessu à u vdev affettatu, u dispositivu di rimpiazzamentu principia à riceve copie o ricustruzzioni di e dati chì deve esse nantu à u dispusitivu mancante. In RAID tradiziunale questu hè chjamatu "rebuilding", è in ZFS hè "resilvering".
Hè impurtante à nutà chì i dispusitivi di sustituzione ùn rimpiazzanu permanentemente i dispusitivi falluti. Questu hè solu un sustitutu tempurale per riduce u tempu chì vdev si degrade. Dopu chì l'amministratore rimpiazza u dispositivu vdev fallutu, a redundanza hè restituita à quellu dispositivu permanente, è SPARE hè disconnected from the vdev and turns to being a spare for the whole pool.
Setti di dati, blocchi è settori
U prossimu settore di blocchi di custruzzione per capiscenu in u nostru viaghju ZFS si rilancià menu à l'hardware è più à fà cù cumu i dati stessi sò urganizati è almacenati. Saltamu uni pochi strati quì - cum'è metaslab - per evità di ingombrare i dettagli, mantenendu una cunniscenza di a struttura generale.
Dataset
Quandu avemu prima creatu un dataset, mostra tuttu u spaziu di piscina dispunibule. Dopu avemu stabilitu a quota - è cambià u puntu di muntagna. Magia !
Zvol hè soprattuttu solu un inseme di dati spogliatu da a so capa di sistema di filesystem, chì rimpiazzamu quì cù un sistema di filesystem ext4 cumplettamente normale.
U settore di dati ZFS hè quasi u listessu cum'è un sistema di schedariu standard muntatu. Cum'è un sistema di fugliale normale, à prima vista pare esse "solu un altru cartulare". Ma cum'è i sistemi di fugliali montati regularmente, ogni settore di dati ZFS hà u so propiu set di proprietà basi.
Prima di tuttu, un dataset pò avè una quota assignata. Se installate zfs set quota=100G poolname/datasetname, tandu ùn puderà micca scrive à u cartulare muntatu /poolname/datasetname più di 100 GiB.
Avvisu a prisenza - è l'assenza - di slashes à l'iniziu di ogni linea? Ogni settore di dati hà u so propiu postu in a ghjerarchia ZFS è in a ghjerarchia di u sistema. Ùn ci hè micca una barra principale in a ghjerarchia ZFS - cumencia cù u nome di a piscina è poi u percorsu da un settore di dati à l'altru. Per esempiu, pool/parent/child per un settore di dati chjamatu child sottu u dataset parenti parent in una piscina cù un nome creativo pool.
Per automaticamente, u puntu di muntagna di un inseme di dati serà equivalente à u so nome in a ghjerarchia ZFS, cù un slash principale - a piscina chjamata pool muntatu cum'è /pool, set di dati parent muntatu in /pool/parent, è u settore di dati di u zitellu child muntatu in /pool/parent/child. Tuttavia, u puntu di muntatura di u sistema di u set di dati pò esse cambiatu.
Sè noi indicà zfs set mountpoint=/lol pool/parent/child, dopu u settore di dati pool/parent/child muntatu in u sistema cum'è /lol.
In più di i datasets, duvemu mintuvà volumi (zvols). Un voluminu hè quasi u listessu cum'è un settore di dati, salvu chì ùn hà micca veramente un sistema di fugliale - hè solu un dispositivu di bloccu. Per esempiu, pudete creà zvol Cù nome mypool/myzvol, dopu formatate cù un sistema di filesystem ext4, è poi muntate quellu sistema di filesystem - avà avete un filesystem ext4, ma cù tutte e funzioni di sicurità di ZFS! Questu pò parè stupidu in un computer, ma hè assai più sensu cum'è backend quandu si esporta un dispositivu iSCSI.
Blocchi
Un schedariu hè rapprisintatu da unu o più blocchi. Ogni bloccu hè almacenatu in un dispositivu virtuale. A dimensione di u bloccu hè di solitu uguali à u paràmetru taglia record, ma pò esse ridutta à 2^ a turnu, s'ellu cuntene metadata o un picculu schedariu.
Avemu veramente veramente Ùn scherzamu micca nantu à l'enorme penalità di prestazione s'ellu si mette un cambiamentu troppu bassu
In un pool ZFS, tutti i dati, cumprese metadata, sò guardati in blocchi. A dimensione massima di bloccu per ogni settore di dati hè definitu in a pruprietà recordsize (taglia di u record). A dimensione di u recordu pò cambià, ma questu ùn cambierà micca a dimensione o u locu di qualsiasi blocchi chì sò digià stati scritti à u settore di dati - affetta solu i blocchi novi cumu sò scritti.
A menu chì ùn hè micca specificatu, a dimensione di l'entrata predeterminata attuale hè 128 KiB. Hè una spezia di un cummerciu duru induve a prestazione ùn serà micca perfetta, ma ùn serà micca terribili in a maiò parte di i casi. Recordsize pò esse stabilitu à qualsiasi valore da 4K à 1M (cù paràmetri supplementari recordsize pudete installà ancu più, ma questu hè raramente una bona idea).
Ogni bloccu si riferisce à e dati di un solu schedariu - ùn pudete micca sprime dui schedarii diffirenti in un bloccu. Ogni schedariu hè custituitu da unu o più blocchi, secondu a so dimensione. Se a dimensione di u schedariu hè più chjuca di a dimensione di u record, serà guardatu in un bloccu più chjucu - per esempiu, un bloccu cù un schedariu di 2 KiB occuparà solu un settore di 4 KiB in u discu.
Se u schedariu hè abbastanza grande per esse bisognu di parechji blocchi, allora tutte e voci à quellu schedariu seranu di grandezza recordsize - cumpresa l'ultima entrata, a parte principale di quale pò esse .
zvol volumi ùn anu micca a pruprietà recordsize - invece anu a pruprietà equivalente volblocksize.
Settori
L'ultimu bloccu di costruzione più basica hè u settore. Hè a più chjuca unità fisica chì pò esse scritta o leghje da un dispositivu host. Per parechji decennii, a maiò parte di i dischi anu utilizatu settori di 512 byte. In questi ghjorni, a maiò parte di e unità sò cunfigurate per settori 4 KiB, è alcuni - in particulare SSD - sò cunfigurati per settori 8 KiB o ancu più grande.
ZFS hà una funzione chì permette di stabilisce manualmente a dimensione di u settore. Sta pruprietà ashift. Un pocu cunfusu, l'ashift hè un putere di dui. Per esempiu, ashift=9 significa taglia di settore 2^9, o 512 bytes.
ZFS dumanda à u sistema operatore infurmazione dettagliata nantu à ogni dispositivu di bloccu quandu hè aghjuntu à un novu vdev, è teoricamente stabilisce automaticamente l'ashift in modu adattatu basatu annantu à questa informazione. Sfurtunatamente, assai unità si trovanu nantu à a so dimensione di u settore per mantene a cumpatibilità cù Windows XP (chì ùn era micca capace di capisce i drive cù altre dimensioni di u settore).
Questu significa chì hè assai cunsigliatu chì l'amministratore ZFS cunnosce a dimensione di u settore attuale di i so dispositi è stabilisce manualmente ashift. Se l'ashift hè troppu chjucu, u numeru di operazioni di lettura / scrittura aumenta astronomicamente. Allora, scrive "settori" di 512 byte à un veru settore di 4 KiB significa avè da scrive u primu "settore", dopu leghje u settore di 4 KiB, mudificàlu cù un secondu "settore" di 512 byte, scrivite torna à u novu. 4 settore KiB, è cusì per ogni entrata.
In u mondu reale, una tale penalità affetta i Samsung EVO SSD, per quale deve applicà ashift=13, ma questi SSD si trovanu nantu à a so dimensione di u settore, è dunque u predeterminatu hè stabilitu ashift=9. A menu chì un amministratore di sistema espertu cambia sta paràmetra, stu SSD funziona più lente HDD magneticu regulare.
Per paragunà, per esse troppu grande ashift ùn ci hè praticamente micca penalità. Ùn ci hè micca un veru successu di rendiment, è l'aumentu di u spaziu inutilizatu hè infinitesimale (o zero se a compressione hè attivata). Dunque, ricumandemu fermamente chì ancu quelli unità chì utilizanu settori di 512 byte installanu ashift=12 o ancu ashift=13per fighjà cun fiducia in u futuru.
Pruprietà ashift hè stallatu per ogni dispusitivu virtuale vdev, è micca per a piscina, cum'è parechje persone pensanu erroneamente - è ùn cambia micca dopu a stallazione. Sì avete colpitu accidentalmente ashift Quandu aghjunghje un novu vdev à una piscina, avete irrevocabilmente contaminatu quella piscina cun un dispositivu di rendiment bassu è, in regula, ùn ci hè micca altra opzione chè di distrughje a piscina è ricominciate. Ancu sguassate vdev ùn vi salverà micca da un paràmetru rottu ashift!
Meccanismo di copia di scrittura
Se un sistema di schedarii regulare hà bisognu di riscrive e dati, mudifica ogni bloccu induve si trova
Un sistema di fugliale di copia in scrittura scrive una nova versione di u bloccu è poi sblocca a versione vechja
In l'astrattu, se ignoremu l'arrangiamentu fisicu propiu di i blocchi, u nostru "cometa di dati" simplifica à un "verme di dati" chì si move da a manca à a diritta à traversu a mappa di u spaziu dispunibule.
Avà pudemu avè una bona idea di cumu funzionanu i snapshots di copia in scrittura - ogni bloccu pò appartene à parechje snapshots, è persisterà finu à chì tutte e snapshots associate sò distrutte.
U mecanismu Copy on Write (CoW) hè a basa fundamentale di ciò chì face ZFS un sistema cusì stupente. U cuncettu basu hè simplice - se dumandate à un sistema di fugliale tradiziunale per cambià un schedariu, farà esattamente ciò chì avete dumandatu. Se dumandate à un sistema di fugliale di copia in scrittura per fà a listessa cosa, vi dicerà "va bè" - ma vi mentirà.
Invece, un sistema di fugliale di copia in scrittura scrive una nova versione di u bloccu mudificatu, è dopu aghjurnà i metadati di u schedariu per unlink u vechju bloccu è associà cù u novu bloccu chì avete scrittu.
Unlinking u vechju bloccu è ligà u novu hè fattu in una sola operazione, perchè ùn pò micca esse interrotta - se resettate u putere dopu chì questu succede, avete una nova versione di u schedariu, è se resettate u putere prima, allora avete a versione vechja. In ogni casu, ùn ci sarà micca cunflittu in u sistema di schedari.
Copy-on-write in ZFS si trova micca solu à u livellu di u sistema di schedari, ma ancu à u livellu di gestione di discu. Questu significa chì ZFS ùn hè micca suscettibile à spazii bianchi in u record () - un fenomenu quandu a striscia era stata registrata solu parzialmente prima chì u sistema s'hè lampatu, cù danni à l'array dopu un reboot. Quì a striscia hè scritta atomicamente, vdev hè sempre sequenziale, è .
ZIL: log d'intenti ZFS
ZFS gestisce le scritture sincrone in una manera speciale - li almacena temporaneamente ma immediatamente in ZIL prima di scriverle in modu permanente cù scrittura asincrona.
Di genere, i dati scritti in ZIL ùn sò mai leghjiti. Ma questu hè pussibule dopu un fallimentu di u sistema
Un SLOG, o un dispositivu LOG secundariu, hè simplicemente un vdev speciale - è preferibile assai veloce - induve ZIL pò esse almacenatu separatamente da u almacenamiento principale.
Dopu un crash, tutti i dati brutti in ZIL sò riproduciti - in questu casu, ZIL hè in SLOG, cusì hè quì chì si riproduce.
Ci sò dui categurie principali di scrittura: sincrona (sincrona) è asincrona (async). Per a maiò parte di i carichi di travagliu, a maiò parte di e scritture sò asincrone - u sistema di fugliale li permette di esse aggregati è emessi in batch, riducendu a frammentazione è aumentendu significativamente u throughput.
I registrazioni sincrone sò una materia completamente diversa. Quandu una applicazione dumanda una scrittura sincrona, dice à u sistema di fugliale: "Avete bisognu di cummettà questu in memoria non volatile. avale avà, è finu à quì ùn ci hè nunda di più chì possu fà ". Per quessa, i scritturi sincroni devenu esse impegnati à u discu immediatamente - è se questu aumenta a frammentazione o riduce u throughput, cusì sia.
ZFS gestisce e scritte sincrone in modu diversu da i sistemi di schedarii regulari, invece di lavà immediatamente in un almacenamentu regulare, ZFS li mette in una zona di almacenamiento speciale chjamata ZFS Intent Log, o ZIL. U truccu hè chì sti records ancu resta in memoria, essendu aggregatu inseme à e richieste di scrittura asincrone normali, per esse più tardi lavate in u almacenamentu cum'è TXGs (Gruppi di Transazzione) cumpletamente normali.
Durante u funziunamentu normale, ZIL hè scrittu è mai lettu. Quandu, dopu à uni pochi di mumenti, i registri da u ZIL sò impegnati à l'almacenamiento principale in TXG regulari da a RAM, sò staccati da u ZIL. L'unica volta chì qualcosa hè lettu da ZIL hè quandu importa una piscina.
Se si verifica un fallimentu ZFS - un crash di u sistema operatore o una mancanza di energia - mentre ci sò dati in u ZIL, quelli dati seranu letti durante a prossima impurtazione di pool (per esempiu, quandu u sistema di failover hè riavviatu). Tuttu ciò chì hè in u ZIL serà lettu, raggruppatu in TXGs, impegnatu in a tenda principale, è dopu staccatu da u ZIL durante u prucessu di impurtazione.
Una di e classi d'aiutu di vdev hè chjamata LOG o SLOG, un dispositivu LOG secundariu. Hà un compitu - per furnisce una piscina cù un dispositivu vdev separatu è, preferibilmente, assai più veloce, cù una resistenza di scrittura assai alta, per almacenà ZIL, invece di almacenà ZIL in u principale vdev storage. ZIL stessu si cumporta u stessu indipendendu da u locu di almacenamentu, ma se u vdev cù LOG hà un rendimentu di scrittura assai altu, allora e scritte sincrone saranu più veloci.
Adding vdev with LOG à a piscina ùn funziona micca ùn pò migliurà a prestazione di scrittura asincrona - ancu s'ellu forza tutte e scritture à ZIL cun zfs set sync=always, Seranu sempre ligati à l'almacenamiento principale in TXG in u listessu modu è à u listessu ritmu cum'è senza u logu. L'unicu miglioramentu direttu di u rendiment hè a latenza di scrittura sincrona (cum'è una velocità di log più alta rende l'operazioni più veloce sync).
Tuttavia, in un ambiente chì hà digià bisognu di assai scritture sincrone, vdev LOG pò accelerà indirettamente e scritte asincrone è letture senza cache. Scaricamentu di i registri ZIL in un vdev LOG separatu significa menu cuntenzione per IOPS nantu à l'almacenamiento primariu, chì migliurà a prestazione di tutte e letture è scrive in una certa misura.
Istantanee
U mecanismu di copia-on-scrittura hè ancu un fundamentu necessariu per i snapshots atomichi ZFS è a replicazione asincrona incrementale. U sistema di schedari attivu hà un arbulu di puntatore chì marca tutte e voci cù dati attuali - quandu pigliate una foto, fate solu una copia di questu arburu di puntatore.
Quandu un registru hè sovrascrittu nantu à u sistema di schedariu attivu, ZFS scrive prima a nova versione di u bloccu in u spaziu inutilizatu. Allora stacca a vechja versione di u bloccu da u sistema di schedariu attuale. Ma se qualchì snapshot fa riferimento à un vechju bloccu, ferma sempre invariatu. U vechju bloccu ùn serà micca veramente restauratu cum'è spaziu liberu finu à chì tutte e snapshots chì riferenu à quellu bloccu sò distrutte!
Replicazione
A mo libreria Steam in 2015 era 158 GiB è includeva 126 schedari. Questu hè abbastanza vicinu à a situazione ottima per rsync - a replicazione ZFS nantu à a reta era "solu" 927% più veloce.
Nant'à a listessa reta, riplicà un unicu 40GB Windows 7 file d'imaghjini di macchina virtuale hè una storia completamente diversa. A replicazione ZFS hè 289 volte più veloce di rsync - o "solu" 161 volte più veloce se site abbastanza espertu per chjamà rsync cù u switch --inplace.
Quandu una maghjina VM scala, rsync issues scale cun ella. A dimensione 1,9 TiB ùn hè micca cusì grande per una maghjina VM moderna, ma hè abbastanza grande chì a replicazione ZFS hè 1148 volte più veloce di rsync, ancu cù l'argumentu rsync --inplace.
Quandu avete capitu cumu funziona i snapshots, serà faciule capisce l'essenza di a replicazione. Siccomu una snapshot hè simplicemente un arbre di puntatori di registru, seguita chì si facemu zfs send snapshot, allora mandemu stu arbre è tutti i registri assuciati cun ellu. Quandu avemu passatu questu zfs send в zfs receive nantu à l'ughjettu di destinazione, scrive u cuntenutu propiu di u bloccu è l'arburu di puntatori chì riferiscenu i blocchi à u settore di dati di destinazione.
E cose diventanu ancu più interessanti nantu à a seconda zfs send. Avemu avà dui sistemi, ognunu cuntene poolname/datasetname@1, è pigliate una nova snapshot poolname/datasetname@2. Dunque, in a piscina fonte chì avete datasetname@1 и datasetname@2, è in a piscina di destinazione ci hè solu a prima snapshot datasetname@1.
Perchè trà a fonte è a destinazione avemu un snapshot cumuni datasetname@1, pudemu fà incrementale zfs send sopra. Quandu avemu dettu à u sistema zfs send -i poolname/datasetname@1 poolname/datasetname@2, compara dui arburi di puntatore. Ogni puntatore chì esiste solu in @2, ovviamente riferite à novi blocchi - cusì avemu bisognu di u cuntenutu di quelli blocchi.
Nantu à un sistema remota, trasfurmazioni incrementali send cum'è simplice. Prima scrivemu tutte e novi entrate incluse in u flussu send, è dopu aghjunghje puntatori à questi blocchi. Voila, avemu @2 in u novu sistema!
A replicazione incrementale asincrona ZFS hè una grande mellura annantu à i metudi precedenti chì ùn sò micca basati in snapshot, cum'è rsync. In i dui casi, solu i dati cambiati sò trasferiti - ma rsync deve prima leghje da u discu tutti i dati da i dui lati per verificà a somma è paragunà. In cuntrastu, a replicazione ZFS ùn leghje nunda altru ch'è l'arbureti di puntatore - è qualsiasi blocchi chì ùn sò micca rapprisentati in a snapshot generale.
Cumpressione integrata
U mecanismu di copia-on-scrittura simplifica ancu u sistema di cumpressione integratu. In un sistema di fugliale tradiziunale, a compressione hè problematica - sia a versione vechja è a nova versione di e dati cambiati sò in u stessu spaziu.
Se cunsiderà un pezzu di dati in u mezu di un schedariu chì principia a so vita cum'è un megabyte di zeri da 0x00000000 è cusì - hè assai faciule di cumpressione in un unicu settore nantu à u discu. Ma chì succede si rimpiazzà stu megabyte di zeri cù un megabyte di dati incompressible, cum'è JPEG o rumore pseudo-aleatoriu? Di colpu, chì megabyte di dati avissi bisognu micca unu, ma 256 4 settori KiB, è solu un settore era riservatu in quellu spaziu discu.
ZFS ùn hà micca stu prublema, postu chì i registri mudificati sò sempre scritti in u spaziu inutilizatu - u bloccu originale occupa solu un settore di 4 KiB, è una nova scrittura pigliarà 256, ma questu ùn hè micca un prublema - un fragmentu mudificatu recentemente da u "mezzu" di u schedariu seria scrittu à u spaziu inutilizatu, indipendentemente da a so dimensione hà cambiatu o micca, cusì hè una situazione completamente normale per ZFS.
A compressione ZFS integrata hè disattivata per automaticamente, è u sistema offre algoritmi pluggable - attualmente inclusi LZ4, gzip (1-9), LZJB è ZLE.
- LZ4 hè un algoritmu di streaming chì offre una compressione è decompressione estremamente rapida è prestazioni di prestazioni per a maiò parte di i casi d'usu - ancu in CPU abbastanza lenti.
- GZIP hè un algoritmu venerabile chì tutti l'utilizatori Unix cunnosci è amanu. Pò esse implementatu cù i livelli di compressione 1-9, cù u rapportu di compressione crescente è l'usu di CPU cum'è avvicinassi à u nivellu 9. L'algoritmu hè adattatu per tutti i casi d'usu di testu (o altri assai comprimibili), ma spessu causa prublemi di CPU altrimenti - l'utilizanu. cun prudenza, soprattuttu à i livelli più alti.
- LZJB - algoritmu originale in ZFS. Hè obsoletu è ùn deve più esse usatu, LZ4 hè superiore in ogni modu.
- MAL - codificazione di livellu zero, codificazione di livellu zero. Ùn tocca micca i dati nurmali in tuttu, ma cumpressa sequenze grandi di zeri. Utile per i setti di dati cumplettamente incompressibili (cum'è JPEG, MP4 o altri formati digià cumpressi) perchè ignora i dati incompressibili ma comprime u spaziu inutilizatu in i registri resultanti.
Ricumandemu cumpressione LZ4 per quasi tutti i casi d'usu; a penalità di rendiment quandu si tratta di dati incompressible hè assai chjuca, è crescita u rendiment per i dati tipici hè significativu. Copia una maghjina di macchina virtuale per una nova installazione di u sistema operatore Windows (OS appena installatu, senza dati à l'internu) cù compression=lz4 passò 27% più veloce chè cù compression=nonein .
ARC - cache di sustituzione adattativa
ZFS hè l'unicu sistema di fugliale mudernu chì sapemu chì usa u so propiu mecanismu di cache di lettura, invece di confià in a cache di pagina di u sistema operatore per almacenà e copie di blocchi letti recentemente in RAM.
Ancu s'è a cache nativa ùn hè micca senza i so prublemi - ZFS ùn pò micca risponde à e novi richieste di allocazione di memoria cum'è u kernel, cusì una nova chjama malloc() L'allocazione di memoria pò fallu se esige RAM occupata attualmente da ARC. Ma ci sò boni motivi per aduprà u vostru propiu cache, almenu per ora.
Tutti i sistemi operativi muderni cunnisciuti, cumpresu MacOS, Windows, Linux è BSD, utilizanu l'algoritmu LRU (Least Recently Used) per implementà a cache di pagina. Questu hè un algoritmu primitivu chì spinge un bloccu in cache "in cima di a fila" dopu ogni lettura è spinge i blocchi "in u fondu di a fila" cum'è necessariu per aghjunghje novi miss di cache (blocchi chì duveranu esse letti da u discu piuttostu cà. da a cache) à a cima.
Di solitu l'algoritmu funziona bè, ma nantu à i sistemi cù grande setti di dati di travagliu, LRU porta facilmente à thrashing-evicting blocchi spessu necessarii per fà spaziu per i blocchi chì ùn saranu mai più letti da a cache.
hè un algoritmu assai menu ingenu chì pò esse cunsideratu un cache "pesatu". Ogni volta chì un bloccu in cache hè lettu, diventa un pocu più pesante è più difficiuli di scacciate - è ancu dopu chì u bloccu hè scacciatu tracciatu durante un certu periodu di tempu. Un bloccu chì hè statu scacciatu ma poi deve esse lettu in u cache diventerà ancu più pesante.
U risultatu finale di tuttu questu hè un cache cù un rapportu di hit assai più altu - u rapportu trà i cache hits (leghje da u cache) è miss (leghje da u discu). Questa hè una statistica estremamente impurtante - micca solu i cache hits stessi serviti ordini di grandezza più veloce, i miss cache ponu ancu esse serviti più rapidamente, postu chì più cache hits ci sò, menu richieste parallele à u discu è più bassa a latenza per quelli rimanenti miss. chì deve esse servitu cù u discu.
cunchiusioni
Avà chì avemu cupertu a semantica di basa di ZFS - cumu funziona a copia in scrittura, è ancu e relazioni trà i pools di almacenamiento, i dispositi virtuali, i blocchi, i settori è i fugliali - simu pronti à discutiri di u rendiment di u mondu reale cù numeri veri.
In a prossima parte, guardemu a prestazione attuale di i pools Vdev è RAIDz specchiati, paragunatu à l'altri, è ancu paragunatu à e topologie RAID tradiziunali di u kernel Linux chì avemu esaminatu. .
À u primu vulemu copre solu i principii - e topologie ZFS stessi - ma dopu un tali Seremu pronti à parlà di cunfigurazione è sintonizazione più avanzata di ZFS, cumpresu l'usu di tipi di vdev ausiliari cum'è L2ARC, SLOG è Special Allocation.
Source: www.habr.com