{"id":83582,"date":"2020-06-01T19:42:21","date_gmt":"2020-06-01T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost"},"modified":"2020-06-01T19:42:21","modified_gmt":"2020-06-01T17:42:21","slug":"osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Fondamenti di ZFS: sistema di archiviazione e prestazioni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Fondamenti
\n
\nQuesta primavera abbiamo gi\u00e0 discusso alcuni temi introduttivi, come ad esempio come verificare la velocit\u00e0 dei tuoi dischi<\/a><\/noindex> e che cos'\u00e8 il RAID<\/a><\/noindex>. Nella seconda abbiamo persino promesso di continuare a esplorare le prestazioni di varie topologie multi-disco in ZFS. Si tratta di un file system di nuova generazione che si sta diffondendo ovunque: da Apple<\/a><\/noindex> fino a Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nBene, oggi \u00e8 il giorno perfetto per conoscere ZFS, curiosi lettori. Sappiate solo che, secondo una stima modesta dell'autore di OpenZFS, Matt Arons, \"\u00e8 davvero complicato\".<\/p>\n

Ma prima di addentrarci nei numeri \u2014 e ci saranno, lo prometto \u2014 riguardanti tutte le configurazioni a otto dischi di ZFS, dobbiamo parlare di come ZFS archivia i dati su disco.<\/i> Zpool, vdev e device<\/p>\n

Zpool, vdev e device<\/h1>\n

\n\"Fondamenti
\nQuesto diagramma del pool completo comprende tre vdev ausiliari, uno per ogni classe, e quattro per RAIDz2.<\/i><\/p>\n

\"Fondamenti
\nDi solito non ci sono motivi per creare un pool di tipi e dimensioni di vdev non corrispondenti \u2014 ma se lo desideri, nulla ti impedisce di farlo.<\/i><\/p>\n

Per comprendere realmente il file system ZFS, \u00e8 fondamentale esaminare attentamente la sua struttura effettiva. In primo luogo, ZFS combina i tradizionali livelli di gestione dei volumi e del file system. In secondo luogo, utilizza un meccanismo transazionale di copia su scrittura. Queste caratteristiche significano che il sistema \u00e8 strutturalmente molto diverso dai normali file system e dai RAID. Il primo insieme di blocchi fondamentali da comprendere include: il pool di archiviazione (zpool), il dispositivo virtuale (vdev) e il dispositivo reale (device).<\/p>\n

zpool<\/h3>\n

\nIl pool di archiviazione zpool \u00e8 la struttura pi\u00f9 alta di ZFS. Ogni pool contiene uno o pi\u00f9 dispositivi virtuali. A sua volta, ciascuno di essi contiene uno o pi\u00f9 dispositivi reali (device). I pool virtuali sono blocchi autonomi. Un singolo computer fisico pu\u00f2 contenere due o pi\u00f9 pool separati, ma ciascuno \u00e8 completamente indipendente dagli altri. I pool non possono condividere dispositivi virtuali.<\/p>\n

La ridondanza di ZFS si applica a livello di dispositivi virtuali, non a livello di pool. A livello di pool non c'\u00e8 alcuna ridondanza: se un qualsiasi dispositivo vdev o un vdev speciale viene perso, allora si perde anche l'intero pool.<\/p>\n

I moderni pool di archiviazione possono sopravvivere alla perdita della cache o del registro del dispositivo virtuale, sebbene possano perdere un piccolo numero di dati spazzatura se perdono il registro vdev durante un'interruzione di corrente o un guasto di sistema.<\/p>\n

Esiste una comune malinteso secondo cui le 'strisce dati' (stripes) di ZFS vengono scritte su tutto il pool. Questo \u00e8 errato. Zpool non \u00e8 affatto un divertente RAID0, \u00e8 piuttosto un divertente JBOD<\/a><\/noindex> con un complesso meccanismo di distribuzione variabile.<\/p>\n

In gran parte, le scritture vengono distribuite tra i dispositivi virtuali disponibili in base allo spazio libero presente, quindi teoricamente tutti verranno riempiti contemporaneamente. Nelle versioni pi\u00f9 recenti di ZFS, viene considerato l'uso corrente (utilizzo) del vdev: se un dispositivo virtuale \u00e8 significativamente pi\u00f9 carico di un altro (ad esempio, a causa di un carico di lettura), verr\u00e0 temporaneamente saltato per la scrittura, nonostante la presenza della maggiore percentuale di spazio libero.<\/p>\n

Il meccanismo di determinazione dell'utilizzo, integrato nei moderni metodi di distribuzione della scrittura di ZFS, pu\u00f2 ridurre la latenza e aumentare la larghezza di banda durante periodi di carico insolito - ma questo non carta bianca<\/i> sull'involontario mescolamento di HDD lenti e SSD veloci in un unico pool. Un pool di questo tipo funzioner\u00e0 comunque alla velocit\u00e0 del dispositivo pi\u00f9 lento, come se fosse interamente composto da tali dispositivi.<\/p>\n

vdev<\/h3>\n

\nOgni pool di archiviazione \u00e8 composto da uno o pi\u00f9 dispositivi virtuali (virtual device, vdev). A sua volta, ogni vdev include uno o pi\u00f9 dispositivi fisici. La maggior parte dei dispositivi virtuali \u00e8 utilizzata per la semplice archiviazione dei dati, ma esistono diverse classi ausiliarie di vdev, tra cui CACHE, LOG e SPECIAL. Ognuno di questi tipi di vdev pu\u00f2 avere una delle cinque topologie: dispositivo singolo (single-device), RAIDz1, RAIDz2, RAIDz3 o specchio (mirror).<\/p>\n

RAIDz1, RAIDz2 e RAIDz3 sono speciali varianti di ci\u00f2 che i vecchi chiamerebbero RAID con parit\u00e0 doppia (diagonale). 1, 2 e 3 si riferiscono al numero di blocchi di parit\u00e0 assegnati a ciascuna striscia di dati. Invece di dischi separati per garantire la parit\u00e0, i dispositivi virtuali RAIDz distribuiscono uniformemente questa parit\u00e0 sui dischi. Un array RAIDz pu\u00f2 perdere tanti dischi quanti sono i suoi blocchi di parit\u00e0; se ne perde un altro, andr\u00e0 in errore e porter\u00e0 con s\u00e9 il pool di archiviazione.<\/p>\n

Negli dispositivi virtuali a specchio (mirror vdev), ogni blocco \u00e8 memorizzato su ciascun dispositivo nel vdev. Sebbene i mirror doppi (two-wide) siano i pi\u00f9 comuni, in un mirror pu\u00f2 esserci qualsiasi numero di dispositivi: nelle installazioni pi\u00f9 grandi, per migliorare le prestazioni di lettura e la tolleranza ai guasti, si usano spesso i mirror tripli. Un mirror vdev pu\u00f2 resistere a qualsiasi guasto finch\u00e9 almeno un dispositivo nel vdev continua a funzionare.<\/p>\n

I vdev singoli, per loro natura, sono pericolosi. Questo dispositivo virtuale non sopravviver\u00e0 a nessun guasto e, se utilizzato come archiviazione o vdev speciale, la sua rottura comporter\u00e0 la perdita di tutto il pool. Fate molta, molta attenzione qui.<\/p>\n

I dispositivi virtuali CACHE, LOG e SPECIAL possono essere creati secondo una qualsiasi delle topologie sopra menzionate, ma ricordate che la perdita di un dispositivo SPECIAL implica la perdita del pool, quindi si raccomanda vivamente una topologia ridondante.<\/p>\n

device<\/h3>\n

\nProbabilmente il termine pi\u00f9 semplice da comprendere in ZFS \u00e8 una semplice unit\u00e0 di archiviazione a blocchi. Ricorda che le unit\u00e0 virtuali sono costituite da singole unit\u00e0 e un pool \u00e8 fatto di unit\u00e0 virtuali.<\/p>\n

I dischi, magnetici o a stato solido, sono i dispositivi di archiviazione a blocchi pi\u00f9 comuni utilizzati come elementi costitutivi del vdev. Tuttavia, qualsiasi dispositivo con un descrittore in \/dev \u00e8 adeguato, quindi \u00e8 possibile utilizzare interi array RAID hardware come singole unit\u00e0.<\/p>\n

Un semplice file raw \u00e8 una delle alternative pi\u00f9 importanti tra le unit\u00e0 a blocchi da cui pu\u00f2 essere costruito un vdev. I pool di test da file sparsi<\/a><\/noindex>\u00a0sono un modo molto comodo per verificare i comandi del pool e vedere quanto spazio \u00e8 disponibile nel pool o nell'unit\u00e0 virtuale di questa topologia.<\/p>\n

\"Fondamenti
\nPuoi creare un pool di test da file sparsi in pochi secondi, ma non dimenticare di eliminare poi l'intero pool e i suoi componenti.<\/i> <\/p>\n

Supponiamo che tu voglia configurare un server con otto dischi e stia pianificando di utilizzare dischi da 10 TB (~9300 GiB) \u2014 ma non sei sicuro di quale topologia si adatti meglio alle tue esigenze. Nell'esempio sopra, costruiamo in pochi secondi un pool di test da file sparsi \u2014 e ora sappiamo che un RAIDz2 vdev di otto dischi da 10 TB offre 50 TiB di capacit\u00e0 utile.<\/p>\n

Un altro tipo speciale di dispositivo \u00e8 lo SPARE (di riserva). I dispositivi hot-swap, a differenza dei normali dispositivi, appartengono all'intero pool e non a un singolo dispositivo virtuale. Se un vdev nel pool si guasta e un dispositivo di riserva \u00e8 connesso al pool e disponibile, si unisce automaticamente al vdev danneggiato.<\/p>\n

Dopo essersi unito al vdev danneggiato, il dispositivo di riserva inizia a ricevere copie o ricostruzioni dei dati che dovrebbero essere sul dispositivo assente. Nel RAID tradizionale questo \u00e8 chiamato ricostruzione, mentre in ZFS \u00e8 noto come \u00abripristino della ridondanza\u00bb.<\/p>\n

\u00c8 importante notare che i dispositivi di riserva non sostituiscono permanentemente i dispositivi guasti. Sono solo una sostituzione temporanea per ridurre il tempo durante il quale si osserva la degradazione del vdev. Dopo che l'amministratore ha sostituito il dispositivo guasto del vdev, viene ripristinata la ridondanza su questo dispositivo permanente, e lo SPARE viene disconnesso dal vdev e torna a funzionare come riserva per l'intero pool.<\/p>\n

Set di dati, blocchi e settori<\/h1>\n

\nIl prossimo insieme di blocchi costitutivi da comprendere nel nostro viaggio attraverso ZFS riguarda pi\u00f9 il modo in cui i dati sono organizzati e memorizzati, piuttosto che l'hardware stesso. Qui stiamo saltando alcuni livelli \u2014 come i metaslab \u2014 per non sovraccaricare i dettagli, mantenendo una comprensione della struttura generale.<\/p>\n

Set di dati (dataset)<\/h3>\n

\n\"Fondamenti
\nQuando creiamo un set di dati per la prima volta, esso mostra tutto lo spazio disponibile nel pool. Poi impostiamo una quota e cambiamo il punto di montaggio. Magia!<\/i> <\/p>\n

\"Fondamenti
\nZvol \u00e8 per la maggior parte un semplice set di dati, privo del proprio strato di file system, che qui sostituiamo con un file system ext4 del tutto normale.<\/i> <\/p>\n

Un dataset ZFS \u00e8 approssimativamente simile a un normale file system montato. Come un file system tradizionale, a prima vista sembra \"solo un'altra cartella\". Ma, come per i file system montati convenzionali, ogni dataset ZFS ha il proprio insieme di propriet\u00e0 di base.<\/p>\n

Innanzitutto, un dataset pu\u00f2 avere una quota assegnata. Se imposti zfs set quota=100G poolname\/datasetname<\/code>, non potrai scrivere nella cartella montata \/poolname\/datasetname<\/code> pi\u00f9 di 100 GiB.<\/p>\n

Hai notato la presenza \u2014 e l'assenza \u2014 delle barre all'inizio di ogni riga? Ogni dataset ha un suo posto sia nella gerarchia ZFS che nella gerarchia di montaggio del sistema. Nella gerarchia ZFS non ci sono barre iniziali \u2014 inizi con il nome del pool e poi il percorso da un dataset all'altro. Ad esempio, pool\/parent\/child<\/code> per un dataset chiamato child<\/code> sotto il dataset genitore parent<\/code> nel pool con un nome creativo pool<\/code>.<\/p>\n

Per impostazione predefinita, il punto di montaggio del dataset sar\u00e0 equivalente al suo nome nella gerarchia ZFS, con una barra all'inizio \u2014 il pool chiamato pool<\/code> verr\u00e0 montato come \/pool<\/code>, il dataset parent<\/code> sar\u00e0 montato in \/pool\/parent<\/code>, e il dataset figlio child<\/code> verr\u00e0 montato in \/pool\/parent\/child<\/code>. Tuttavia, il punto di mount del dataset pu\u00f2 essere modificato.<\/p>\n

Se indichiamo zfs set mountpoint=\/lol pool\/parent\/child<\/code>, allora il dataset pool\/parent\/child<\/code> sar\u00e0 montato nel sistema come \/lol<\/code>.<\/p>\n

Oltre ai dataset, dobbiamo menzionare i volumi (zvols). Un volume \u00e8 quasi equivalente a un dataset, ad eccezione del fatto che non ha effettivamente un file system \u2014 \u00e8 semplicemente un dispositivo a blocchi. Puoi, ad esempio, creare un zvol<\/code> chiamato mypool\/myzvol<\/code>, poi formattarlo con un file system ext4, per poi montare questo file system \u2014 ora hai un file system ext4, ma con tutte le funzionalit\u00e0 di sicurezza di ZFS! Potrebbe sembrare sciocco su un singolo computer, ma ha molto pi\u00f9 senso come backend nell'esportazione di un dispositivo iSCSI.<\/p>\n

Blocchi<\/h3>\n

\n\"Fondamenti
\nUn file \u00e8 rappresentato da uno o pi\u00f9 blocchi. Ogni blocco \u00e8 memorizzato su un dispositivo virtuale. La dimensione del blocco di solito corrisponde al parametro recordsize<\/b>, ma pu\u00f2 essere ridotta a 2^ashift<\/b>, se contiene metadati o un file di piccole dimensioni.<\/i><\/p>\n

\"Fondamenti
\nNoi veramente, davvero<\/b> non scherziamo riguardo al enorme danno alle prestazioni se impostiamo un ashift troppo piccolo.<\/i><\/p>\n

Nel pool ZFS, tutti i dati, comprese le metadata, vengono memorizzati in blocchi. La dimensione massima del blocco per ogni set di dati \u00e8 definita nella propriet\u00e0 recordsize<\/code> (dimensione del record). La dimensione del record pu\u00f2 variare, ma ci\u00f2 non cambier\u00e0 la dimensione o la posizione di eventuali blocchi gi\u00e0 scritti nel set di dati \u2014 si applica solo ai nuovi blocchi man mano che vengono scritti.<\/p>\n

Se non diversamente specificato, la dimensione del record corrente per impostazione predefinita \u00e8 128 KiB. Questa \u00e8 una sorta di compromesso, dove le prestazioni non saranno ottimali, ma nemmeno terribili nella maggior parte dei casi. Recordsize<\/code> pu\u00f2 essere impostato su qualsiasi valore da 4K a 1M (con impostazioni aggiuntive recordsize<\/code> pu\u00f2 essere impostato ancora pi\u00f9 in alto, ma di solito non \u00e8 una buona idea).<\/p>\n

Ogni blocco fa riferimento ai dati di un solo file \u2014 non puoi comprimere due file diversi in un solo blocco. Ogni file \u00e8 composto da uno o pi\u00f9 blocchi, a seconda delle dimensioni. Se la dimensione del file \u00e8 inferiore alla dimensione del record, verr\u00e0 memorizzato in un blocco di dimensioni inferiori \u2014 ad esempio, un blocco con un file di 2 KiB occuper\u00e0 solo un settore di 4 KiB sul disco.<\/p>\n

I volumi zvol non hanno la propriet\u00e0 recordsize<\/code>\u00a0\u2014 invece, hanno una propriet\u00e0 equivalente volblocksize<\/code>.<\/p>\n

Settori<\/h3>\n

\nL'ultimo e pi\u00f9 fondamentale elemento costitutivo \u00e8 il settore. Questa \u00e8 l'unit\u00e0 fisica pi\u00f9 piccola che pu\u00f2 essere scritta o letta dal dispositivo di base. Per decenni, la maggior parte dei dischi ha utilizzato settori da 512 byte. Negli ultimi tempi, la maggior parte dei dischi \u00e8 configurata per settori da 4 KiB, e in alcuni \u2014 specialmente gli SSD \u2014 settori da 8 KiB o anche di pi\u00f9.<\/p>\n

Nel sistema ZFS c'\u00e8 una propriet\u00e0 che consente di impostare manualmente la dimensione del settore. Questa propriet\u00e0 ashift<\/code>. \u00c8 un po' confuso, poich\u00e9 ashift \u00e8 una potenza di due. Ad esempio, ashift=9<\/code> indica una dimensione del settore di 2^9, ossia 512 byte.<\/p>\n

ZFS richiede al sistema operativo informazioni dettagliate su ogni dispositivo di blocco quando viene aggiunto a un nuovo vdev e, teoricamente, imposta automaticamente ashift in modo corretto in base a queste informazioni. Sfortunatamente, molti dischi mentono sulle loro dimensioni di settori per mantenere la compatibilit\u00e0 con Windows XP (che non era in grado di comprendere dischi con dimensioni di settore diverse).<\/p>\n

Ci\u00f2 significa che \u00e8 fortemente consigliato all'amministratore di ZFS conoscere le reali dimensioni di settore dei propri dispositivi e impostarle manualmente. ashift<\/code>. Se ashift \u00e8 impostato troppo basso, il numero di operazioni di lettura\/scrittura aumenta in modo astronomico. Scrivere 'settori' da 512 byte in un settore reale da 4 KiB implica la necessit\u00e0 di scrivere il primo 'settore', quindi leggere il settore da 4 KiB, modificarlo con il secondo 'settore' da 512 byte, scriverlo di nuovo in un nuovo settore da 4 KiB e cos\u00ec via per ogni scrittura.<\/p>\n

Nel mondo reale, questa penalizzazione colpisce i solid state drive Samsung EVO, per cui dovrebbe applicarsi ashift=13<\/code>, ma questi SSD mentono sulle loro dimensioni di settore, e quindi viene impostato per impostazione predefinita ashift=9<\/code>. Se un amministratore di sistema esperto non modifica questo parametro, allora questo SSD funziona pi\u00f9 lentamente<\/i> di un normale HDD magnetico.<\/p>\n

A titolo di confronto, non c'\u00e8 praticamente alcuna penalit\u00e0 per dimensioni eccessive. ashift<\/code> Non c'\u00e8 un reale abbassamento delle prestazioni, e l'aumento dello spazio inutilizzato \u00e8 infinitesimale (o pari a zero se la compressione \u00e8 attivata). Pertanto, raccomandiamo vivamente di installare anche su quei dischi che utilizzano realmente settori da 512 byte ashift=12<\/code> o addirittura ashift=13<\/code>, per guardare fiduciosamente al futuro.<\/p>\n

Questa impostazione ashift<\/code> \u00e8 applicata a ogni dispositivo virtuale vdev, e non al pool<\/i>, come molti erroneamente pensano \u2014 e non pu\u00f2 essere modificata dopo l'installazione. Se accidentalmente hai impostato ashift<\/code> quando aggiungi un nuovo vdev al pool, hai compromesso irreversibilmente questo pool con un dispositivo a bassa prestazione e, in genere, non c'\u00e8 altra soluzione che distruggere il pool e ricominciare da capo. Anche la rimozione del vdev non salver\u00e0 da una configurazione errata. ashift<\/code>!<\/p>\n

Il meccanismo di copia in scrittura<\/h3>\n

\n\"Fondamenti
\nSe a un normale file system serve riscrivere i dati, modifica ogni blocco dove si trova.<\/i><\/p>\n

\"Fondamenti
\nIl file system con copia alla scrittura registra una nuova versione del blocco e poi sblocca la versione precedente.<\/i><\/p>\n

\"Fondamenti
\nIn senso astratto, ignorando la reale posizione fisica dei blocchi, la nostra 'cometa dei dati' si semplifica in un 'verme dei dati', che si muove da sinistra a destra sulla mappa dello spazio disponibile.<\/i><\/p>\n

\"Fondamenti
\nOra possiamo avere una buona comprensione di come funzionano gli snapshot con copia alla scrittura: ogni blocco pu\u00f2 appartenere a pi\u00f9 snapshot e rimarr\u00e0 fino a quando non verranno eliminati tutti gli snapshot associati.<\/i><\/p>\n

Il meccanismo di copia alla scrittura (Copy on Write, CoW) \u00e8 la base fondamentale di ci\u00f2 che rende ZFS un sistema cos\u00ec straordinario. Il concetto principale \u00e8 semplice: se chiedi a un file system tradizionale di modificare un file, far\u00e0 esattamente ci\u00f2 che hai richiesto. Se chiedi a un file system con copia alla scrittura di fare lo stesso, dir\u00e0 'va bene' \u2014 ma ti mentir\u00e0.<\/p>\n

Invece, il file system con copia su scrittura registra una nuova versione del blocco modificato e poi aggiorna i metadati del file per rompere il legame con il vecchio blocco e legarsi al nuovo blocco che hai appena scritto.<\/p>\n

Il distacco del vecchio blocco e il legame del nuovo avviene in un'unica operazione, quindi non pu\u00f2 essere interrotto: se si spegne l'alimentazione dopo che questo avviene, si avr\u00e0 una nuova versione del file, mentre se si spegne prima, si avr\u00e0 la vecchia versione. In ogni caso, non ci saranno conflitti nel file system.<\/p>\n

La copia su scrittura in ZFS avviene non solo a livello di file system, ma anche a livello di gestione dei dischi. Ci\u00f2 significa che ZFS non \u00e8 soggetta al problema dello scrivere un buco (buco nel RAID<\/a><\/noindex>) \u2014 un fenomeno in cui la striscia \u00e8 stata solo parzialmente registrata prima di un crash del sistema, causando danni all'array dopo il riavvio. Qui la striscia viene scritta in modo atomico, e vdev \u00e8 sempre coerente, e Bob \u00e8 tuo zio<\/a><\/noindex>.<\/p>\n

ZIL: il log delle intenzioni di ZFS<\/h3>\n

\n\"Fondamenti
\nIl sistema ZFS gestisce le scritture sincrone in modo speciale: le memorizza temporaneamente, ma immediatamente, nello ZIL, prima di scriverle in modo permanente insieme alle scritture asincrone.<\/i><\/p>\n

\"Fondamenti
\nDi solito, i dati scritti nello ZIL non vengono mai letti di nuovo. Tuttavia, ci\u00f2 \u00e8 possibile dopo un guasto del sistema.<\/i><\/p>\n

\"Fondamenti
\nSLOG, o dispositivo di LOG secondario, \u00e8 semplicemente un vdev speciale \u2013 e preferibilmente molto veloce \u2013 dove lo ZIL pu\u00f2 essere memorizzato separatamente dallo storage principale.<\/i><\/p>\n

\"Fondamenti
\nDopo un guasto, tutti i dati non puliti nello ZIL vengono riprodotti: in questo caso lo ZIL si trova su SLOG, quindi vengono riprodotti proprio da l\u00ec.<\/i><\/p>\n

Ci sono due categorie principali di operazioni di scrittura: sincrone (sync) e asincrone (async). Per la maggior parte dei carichi di lavoro, la stragrande maggioranza delle operazioni di scrittura \u00e8 asincrona: il file system consente di aggregarle e di emetterle in pacchetti, riducendo la frammentazione e aumentando significativamente la larghezza di banda.<\/p>\n

Le scritture sincrone sono un'altra cosa. Quando un'applicazione richiede una scrittura sincrona, comunica al file system: \u00abDevi registrarlo nella memoria non volatile proprio ora<\/i>, e fino ad allora non posso fare altro\u201d. Pertanto, le registrazioni sincrone devono essere immediatamente registrate su disco \u2014 e se questo aumenta la frammentazione o riduce la larghezza di banda, cos\u00ec sia.<\/p>\n

ZFS gestisce le registrazioni sincrone in modo diverso rispetto ai normali file system \u2014 invece di scriverle immediatamente nello storage ordinario, ZFS le registra in un'area di archiviazione speciale chiamata ZFS Intent Log, o ZIL. Il trucco \u00e8 che queste registrazioni anche<\/i> rimangono in memoria, aggregate insieme alle normali richieste di scrittura asincrona, per essere successivamente scritte nello storage come normali TXG (gruppi di transazioni, Transaction Groups).<\/p>\n

In condizioni di funzionamento normale, il ZIL viene registrato e mai pi\u00f9 letto. Quando, dopo pochi istanti, le registrazioni dal ZIL vengono registrate nello storage principale nei normali TXG dalla memoria, vengono scollegate dal ZIL. L'unico momento in cui qualcosa viene letto dal ZIL \u00e8 durante l'importazione del pool.<\/p>\n

Se si verifica un guasto di ZFS \u2014 un guasto del sistema operativo o un'interruzione di corrente \u2014 quando ci sono dati nel ZIL, questi dati verranno letti al momento del successivo import del pool (ad esempio, durante il riavvio di un sistema dopo un crash). Tutto ci\u00f2 che si trova nel ZIL sar\u00e0 letto, raggruppato in TXG, registrato nell'archivio principale e poi scollegato dal ZIL durante il processo di importazione.<\/p>\n

Uno dei classi ausiliarie di vdev si chiama LOG o SLOG, un dispositivo secondario LOG. Ha un'unica funzione: fornire al pool un dispositivo vdev separato e, preferibilmente, molto pi\u00f9 veloce, con un'alta resistenza alla scrittura, per memorizzare il ZIL, invece di memorizzare il ZIL nel principale archivio vdev. Il ZIL si comporta allo stesso modo indipendentemente dalla posizione di archiviazione, ma se il vdev con LOG ha un'elevata performance in scrittura, le scritture sincrone avverranno pi\u00f9 rapidamente.<\/p>\n

Aggiungere un vdev con LOG al pool in alcun modo pu\u00f2<\/b> migliorare le prestazioni della scrittura asincrona \u2014 anche se si costringono tutte le scritture nel ZIL utilizzando zfs set sync=always<\/code>, saranno comunque legati allo storage principale in TXG nello stesso modo e con lo stesso ritmo di quando non \u00e8 presente il log. L'unico miglioramento delle prestazioni diretto \u00e8 la latenza della scrittura sincrona (poich\u00e9 una maggiore velocit\u00e0 del log accelera l'esecuzione delle operazioni sync<\/code>).<\/p>\n

Tuttavia, in un ambiente che richiede gi\u00e0 un elevato numero di scritture sincrone, vdev LOG pu\u00f2 indirettamente accelerare le scritture asincrone e le letture non memorizzate nella cache. Scaricare le registrazioni ZIL in un vdev LOG separato significa meno concorrenza per gli IOPS nello storage primario, il che migliora, in una certa misura, le prestazioni di tutte le operazioni di lettura e scrittura.<\/p>\n

Snapshot<\/h3>\n

\nIl meccanismo di copia su scrittura \u00e8 anche una base necessaria per gli snapshot atomici di ZFS e la replica asincrona incrementale. In un file system attivo c'\u00e8 un albero di puntatori che segna tutte le registrazioni con i dati correnti: quando esegui uno snapshot, stai semplicemente creando una copia di questo albero di puntatori.<\/p>\n

Quando una registrazione viene sovrascritta nel file system attivo, ZFS prima scrive una nuova versione del blocco in uno spazio non utilizzato. Successivamente, scollega la vecchia versione del blocco dal file system attuale. Tuttavia, se uno snapshot fa riferimento al vecchio blocco, rimane invariato. Il vecchio blocco non sar\u00e0 effettivamente restituito come spazio libero finch\u00e9 tutti gli snapshot che fanno riferimento a quel blocco non saranno eliminati!<\/p>\n

Replica<\/h3>\n

\n\"Fondamenti
\nNel 2015, la mia libreria Steam occupava 158 GiB e includeva 126.927 file. Questa \u00e8 una situazione piuttosto vicina all'ottimale per rsync: la replica ZFS sulla rete era \"solo\" il 750% pi\u00f9 veloce.<\/i><\/p>\n

\"Fondamenti
\nNella stessa rete, la replica di un file immagine di una macchina virtuale Windows 7 di 40 gigabyte \u00e8 una storia completamente diversa. La replica ZFS avviene 289 volte pi\u00f9 velocemente di rsync, oppure \"soltanto\" 161 volte pi\u00f9 velocemente, se hai la conoscenza sufficiente per chiamare rsync con l'opzione —inplace.<\/i><\/p>\n

\"Fondamenti
\nQuando un'immagine di macchina virtuale viene scalata, i problemi di rsync si scalano insieme a essa. Una dimensione di 1,9 TiB non \u00e8 cos\u00ec grande per un'immagine di macchina virtuale moderna, ma \u00e8 abbastanza grande perch\u00e9 la replica ZFS risulti 1148 volte pi\u00f9 veloce di rsync, anche con l'argomento rsync —inplace.<\/i><\/p>\n

Una volta compreso come funzionano gli snapshot, sar\u00e0 facile afferrare il concetto di replica. Poich\u00e9 uno snapshot \u00e8 semplicemente un albero di puntatori ai record, ne consegue che se creiamo zfs send<\/code> uno snapshot, inviamo sia questo albero che tutti i record ad esso associati. Quando trasferiamo questo zfs send<\/code> in zfs receive<\/code> sull'oggetto di destinazione, registra sia il contenuto effettivo del blocco che l'albero di puntatori che si riferiscono ai blocchi nel dataset di destinazione.<\/p>\n

Tutto diventa ancora pi\u00f9 interessante al secondo zfs send<\/code>. Ora abbiamo due sistemi, ciascuno contenente poolname\/datasetname@1<\/code>, e stai creando un nuovo snapshot poolname\/datasetname@2<\/code>. Quindi nel pool di origine hai datasetname@1<\/code> e datasetname@2<\/code>, mentre nel pool di destinazione c'\u00e8 solo il primo snapshot datasetname@1<\/code>.<\/p>\n

. Poich\u00e9 abbiamo uno snapshot comune tra sorgente e destinazione, possiamo creare datasetname@1<\/code>incrementale sopra di esso. Quando parliamo al sistema<\/i> zfs send<\/code> sopra di esso. Quando parliamo del sistema zfs send -i poolname\/datasetname@1 poolname\/datasetname@2<\/code>, confronta due alberi di puntatori. Qualsiasi puntatore che esiste solo in @2<\/code>, ovviamente, si riferisce a nuovi blocchi \u2013 quindi avremo bisogno del contenuto di questi blocchi.<\/p>\n

Nella sistema remota, l'elaborazione dell'incrementale send<\/code> \u00e8 altrettanto semplice. Prima scriviamo tutte le nuove voci incluse nel flusso send<\/code>, e poi aggiungiamo i puntatori a questi blocchi. Ecco fatto, abbiamo @2<\/code> nel nuovo sistema!<\/p>\n

La replica incrementale asincrona di ZFS \u00e8 un'enorme miglioria rispetto ai metodi precedenti che non si basano sugli snapshot, come rsync. In entrambi i casi, vengono trasmessi solo i dati modificati \u2013 ma rsync deve prima leggere<\/i> dal disco tutti i dati da entrambe le parti per controllare il checksum e confrontarlo. A differenza di questo, la replica ZFS non legge nulla tranne gli alberi di puntatori \u2013 e qualsiasi blocco non rappresentato nell'snapshot comune.<\/p>\n

Compressione integrata<\/h3>\n

\nIl meccanismo di copia durante la registrazione semplifica anche il sistema di compressione integrato. Nelle tradizionali file system, la compressione \u00e8 problematica: sia la vecchia versione che la nuova versione dei dati modificati si trovano nello stesso spazio.<\/p>\n

Considerando un frammento di dati a met\u00e0 file, che inizia la sua vita come un megabyte di zeri da 0x00000000 e cos\u00ec via, \u00e8 molto facile comprimerlo in un unico settore del disco. Ma cosa succede se sostituiamo quel megabyte di zeri con un megabyte di dati non compressi, come JPEG o rumore pseudo-casuale? Improvvisamente, quel megabyte di dati avr\u00e0 bisogno non di uno, ma di 256 settori da 4 KiB, mentre in quel punto del disco \u00e8 riservato solo un settore.<\/p>\n

ZFS non ha questo problema, poich\u00e9 le scritture modificate vengono sempre registrate in uno spazio non utilizzato: il blocco originale occupa solo un settore da 4 KiB, mentre la nuova scrittura occuper\u00e0 256, ma questo non \u00e8 un problema; il frammento recentemente modificato della 'met\u00e0' del file sarebbe stato registrato in uno spazio non utilizzato indipendentemente dal fatto che la sua dimensione cambiasse o meno, quindi per ZFS si tratta di una situazione del tutto normale.<\/p>\n

La compressione ZFS \u00e8 disabilitata per impostazione predefinita, e il sistema offre algoritmi plug-in \u2014 attualmente tra cui LZ4, gzip (1-9), LZJB e ZLE.<\/p>\n

Se il file \u00e8 sufficientemente grande e richiede pi\u00f9 blocchi, allora tutte le voci relative a questo file avranno la dimensione recordsize<\/code>\u00a0\u2014 inclusa l'ultima voce, la cui parte principale potrebbe risultare spazio non utilizzato<\/a><\/noindex>.<\/p>\n