{"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 argomenti introduttivi, ad esempio, come controllare la velocit\u00e0 dei vostri dischi<\/a><\/noindex> e cosa sia il RAID<\/a><\/noindex>. Nella seconda di esse abbiamo persino promesso di continuare a esplorare le prestazioni delle diverse topologie multi-disco in ZFS. Questo \u00e8 un file system di nuova generazione che sta attualmente venendo implementato ovunque: da Apple<\/a><\/noindex> fino a Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nBene, oggi \u00e8 il giorno perfetto per conoscere ZFS, cari lettori curiosi. Sappiate solo che, secondo la modesta stima dello sviluppatore di OpenZFS, Matt Arends, \u2018\u00e8 davvero complicato\u2019.<\/p>\n

Ma prima di arrivare ai numeri - e ci saranno, promesso - su tutte le varianti della configurazione a otto dischi di ZFS, dobbiamo parlare di come come<\/i> ZFS memorizza i dati su disco.<\/p>\n

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

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

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

Per veramente comprendere il file system ZFS, \u00e8 necessario dare un'occhiata attenta alla 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 di transazione di copia all'atto della scrittura. Queste caratteristiche significano che il sistema \u00e8 strutturalmente molto diverso dai normali file system e dagli array RAID. Il primo set di elementi costitutivi fondamentali per la comprensione: \u00e8 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 superiore di ZFS. Ogni pool contiene uno o pi\u00f9 dispositivi virtuali. A sua volta, ognuno 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 ognuno \u00e8 completamente indipendente dagli altri. I pool non possono condividere dispositivi virtuali.<\/p>\n

La ridondanza di ZFS si trova a livello dei dispositivi virtuali, non a livello dei pool. A livello dei pool non c'\u00e8 assolutamente alcuna ridondanza - se un disco vdev o un vdev speciale va perso, si perde anche l'intero pool.<\/p>\n

Le moderne pool di archiviazione possono sopportare la perdita della cache o del diario del dispositivo virtuale, sebbene possano perdere una piccola quantit\u00e0 di dati sporchi se perdi il diario vdev durante un'interruzione di corrente o un guasto di sistema.<\/p>\n

C'\u00e8 un'eccessiva convinzione che le 'strisce di dati' (striping) in ZFS vengano scritte su tutto il pool. Questo \u00e8 errato. Zpool non \u00e8 affatto un divertente RAID0, \u00e8 piuttosto un divertente JBOD<\/a><\/noindex> con un meccanismo di distribuzione variabile complesso.<\/p>\n

Per la maggior parte, le scritture vengono distribuite tra i dispositivi virtuali disponibili in base allo spazio libero disponibile, in modo che, teoricamente, tutti vengano 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 ci sia spazio libero disponibile.<\/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 in periodi di carico di lavoro insolitamente elevato, ma questo non \u00e8 un lasciapassare<\/i> per una mescolanza involontaria di HDD lenti e SSD veloci in un unico pool. Un pool impari funzioner\u00e0 comunque alla velocit\u00e0 del dispositivo pi\u00f9 lento, come se fosse composto esclusivamente 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 viene utilizzata per la semplice archiviazione dei dati, ma ci sono 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 mirror.<\/p>\n

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

Nei dispositivi virtuali a specchio (mirror vdev), ogni blocco \u00e8 memorizzato su ciascun dispositivo nel vdev. Sebbene i doppi specchi (two-wide) siano i pi\u00f9 comuni, nello specchio pu\u00f2 esserci qualsiasi numero arbitrario di dispositivi; nelle installazioni pi\u00f9 grandi, per migliorare le prestazioni di lettura e la tolleranza ai guasti, spesso si utilizzano i tripli. Uno specchio vdev pu\u00f2 sopravvivere a qualsiasi guasto, purch\u00e9 almeno un dispositivo nel vdev continui a funzionare.<\/p>\n

I vdev singoli sono intrinsecamente pericolosi. Un tale dispositivo virtuale non sopravviver\u00e0 a nessun guasto; e se viene utilizzato come storage o vdev speciale, il suo guasto porter\u00e0 alla distruzione dell'intero pool. Fai attenzione qui, molto, molto attenzione.<\/p>\n

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

dispositivo<\/h3>\n

\nProbabilmente \u00e8 il termine pi\u00f9 semplice da capire in ZFS \u2014 \u00e8 letteralmente un dispositivo a blocchi di accesso casuale. Ricorda che i dispositivi virtuali sono composti da dispositivi separati, e il pool \u00e8 fatto di dispositivi virtuali.<\/p>\n

I dischi \u2014 magnetici o a stato solido \u2014 sono i dispositivi a blocchi pi\u00f9 comuni utilizzati come mattoni per il vdev. Tuttavia, qualsiasi dispositivo con un descrittore in \/dev \u00e8 adatto \u2014 quindi interi array RAID hardware possono essere utilizzati come dispositivi separati.<\/p>\n

Un semplice file raw \u00e8 uno dei pi\u00f9 importanti dispositivi a blocchi alternativi da cui pu\u00f2 essere costruito un vdev. I pool di test da file sparsi<\/a><\/noindex>\u00a0sono un modo molto utile per verificare i comandi del pool e vedere quanta memoria \u00e8 disponibile nel pool o nel dispositivo virtuale di questa topologia.<\/p>\n

\"Fondamenti
\nPuoi creare un pool di test da file sparsi in pochi secondi, ma non dimenticare di rimuovere successivamente 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) - ma non sei sicuro su quale topologia si adatti meglio alle tue esigenze. Nell'esempio sopra, costruiamo in pochi secondi un pool di test da file sparsi e ora sappiamo che un vdev RAIDz2 composto da otto dischi da 10 TB offre 50 TiB di capacit\u00e0 utile.<\/p>\n

Un'altra classe speciale di dispositivi \u00e8 SPARE (riserva). I dispositivi hot-swappable, a differenza dei normali dispositivi, appartengono a tutto il pool, non a un singolo dispositivo virtuale. Se un vdev nel pool fallisce e un dispositivo di riserva \u00e8 connesso al pool e disponibile, si unir\u00e0 automaticamente al vdev danneggiato.<\/p>\n

Dopo che il dispositivo di riserva si \u00e8 collegato al vdev danneggiato, inizia a ricevere copie o ricostruzioni dei dati che dovrebbero essere sul dispositivo mancante. Nel RAID tradizionale, questo \u00e8 chiamato recupero (rebuilding), mentre in ZFS \u00e8 'ripristino della ridondanza' (resilvering).<\/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 verifica la degradazione del vdev. Dopo che l'amministratore sostituisce il dispositivo guasto nel vdev, la ridondanza viene ripristinata su questo dispositivo permanente, e il SPARE si disconnette dal vdev e torna a funzionare come riserva per l'intero pool.<\/p>\n

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

\nIl prossimo set di mattoni da capire nel nostro viaggio attraverso ZFS riguarda non tanto l'hardware, quanto il modo in cui i dati stessi sono organizzati e memorizzati. Qui saltando alcuni livelli \u2014 come il metaslab \u2014 per non sovraccaricare i dettagli, mantenendo la comprensione della struttura generale.<\/p>\n

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

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

\"Fondamenti
\nZvol \u00e8 per lo pi\u00f9 semplicemente un set di dati privo del proprio strato di file system, che qui sostituiamo con un file system ext4 del tutto normale.<\/i> <\/p>\n

Il dataset ZFS \u00e8 sostanzialmente simile a un file system montato standard. Proprio come un normale file system, a prima vista sembra \"solo un'altra cartella\". Ma, come con i normali file system montati, ogni dataset ZFS ha un insieme proprio di propriet\u00e0 fondamentali.<\/p>\n

Prima di tutto, un dataset pu\u00f2 avere una quota assegnata. Se si imposta zfs set quota=100G poolname\/datasetname<\/code>, non sar\u00e0 possibile scrivere nella cartella montata \/poolname\/datasetname<\/code> pi\u00f9 di 100 GiB.<\/p>\n

Hai notato la presenza \u2013 e l'assenza \u2013 di slash all'inizio di ogni riga? Ogni dataset ha il proprio posto sia nell'gerarchia ZFS che nell'gerarchia di montaggio del sistema. Nell'gerarchia ZFS non c'\u00e8 uno slash iniziale: si inizia con il nome del pool e poi il percorso da un dataset all'altro. Ad esempio, pool\/parent\/child<\/code> per un dataset con il nome child<\/code> sotto il dataset genitore parent<\/code> in un pool con un nome creativo pool<\/code>.<\/p>\n

Per impostazione predefinita, il punto di montaggio del dataset sar\u00e0 equivalente al suo nome nell'gerarchia ZFS, con uno slash all'inizio: il pool con nome pool<\/code> viene montato come \/pool<\/code>, il dataset parent<\/code> viene montato in \/pool\/parent<\/code>, e il dataset figlio child<\/code> viene montato in \/pool\/parent\/child<\/code>. Tuttavia, il punto di montaggio del dataset del sistema pu\u00f2 essere modificato.<\/p>\n

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

In aggiunta ai dataset, dobbiamo menzionare i volumi (zvols). Un volume \u00e8 sostanzialmente simile a un dataset, eccetto che in esso non c'\u00e8 effettivamente un file system \u2013 \u00e8 semplicemente un dispositivo a blocchi. Puoi, ad esempio, creare zvol<\/code> con il nome mypool\/myzvol<\/code>, quindi formattarlo con il file system ext4, e poi montare questo file system \u2013 ora hai un file system ext4, ma con il supporto di tutte le funzionalit\u00e0 di sicurezza ZFS! Pu\u00f2 sembrare strano su un singolo computer, ma ha molto pi\u00f9 senso come backend quando si esporta 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 singolo dispositivo virtuale. La dimensione del blocco \u00e8 generalmente uguale 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
\nNon stiamo davvero scherzando riguardo al danno enorme alle prestazioni se si imposta un ashift troppo piccolo. in effetti<\/b> non stiamo scherzando riguardo ai danni enormi alle prestazioni se imposti un ashift troppo piccolo.<\/i><\/p>\n

Nel pool ZFS, tutti i dati, comprese le metainformazioni, sono memorizzati in blocchi. La dimensione massima del blocco per ciascun dataset \u00e8 definita nella propriet\u00e0 recordsize<\/code> (dimensione del record). La dimensione del record pu\u00f2 variare, ma questo non influenzer\u00e0 la dimensione o la posizione di qualsiasi blocco che \u00e8 gi\u00e0 stato scritto nel dataset \u2014 vale solo per i nuovi blocchi man mano che vengono scritti.<\/p>\n

Se non diversamente specificato, la dimensione del record attuale per impostazione predefinita \u00e8 di 128 KiB. \u00c8 una sorta di compromesso non banale, dove le prestazioni non saranno ideali, ma nemmeno disastrose nella maggior parte dei casi. Recordsize<\/code> pu\u00f2 essere impostato su qualsiasi valore da 4K a 1M (con ulteriori configurazioni 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 solo ai dati di un singolo file \u2014 non \u00e8 possibile inserire due file diversi in un unico blocco. Ogni file \u00e8 composto da uno o pi\u00f9 blocchi, a seconda della dimensione. Se la dimensione del file \u00e8 inferiore alla dimensione del record, verr\u00e0 memorizzato in un blocco di dimensioni inferiori \u2014 per 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 basilare mattoncino \u00e8 il settore. Questa \u00e8 l'unit\u00e0 fisica pi\u00f9 piccola che pu\u00f2 essere scritta o letta dal dispositivo sottostante. Per decenni, la maggior parte dei dischi ha utilizzato settori da 512 byte. Ultimamente, la maggior parte dei dischi \u00e8 configurata per settori da 4 KiB, e in alcuni \u2014 specialmente SSD \u2014 settori da 8 KiB o anche di pi\u00f9.<\/p>\n

Nel sistema ZFS esiste 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> significa una dimensione del settore di 2^9, ovvero 512 byte.<\/p>\n

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

Questo significa che l'amministratore ZFS \u00e8 fortemente incoraggiato a conoscere la reale dimensione del settore delle proprie unit\u00e0 e a impostarla manualmente ashift<\/code>. Se ashift \u00e8 impostato troppo piccolo, il numero di operazioni di lettura\/scrittura aumenta astronomicamente. Scrivere \"settori\" da 512 byte in un vero settore da 4 KiB implica la necessit\u00e0 di scrivere prima il \"settore\" poi leggere il settore da 4 KiB, modificarlo con il secondo \"settore\" da 512 byte, riscriverlo nel nuovo settore da 4 KiB e cos\u00ec via per ogni scrittura.<\/p>\n

Nel mondo reale, questa penalizzazione colpisce gravemente i dischi a stato solido Samsung EVO, per i quali deve essere applicato ashift=13<\/code>, ma questi SSD mentono sulla loro dimensione di settore, e quindi per impostazione predefinita viene fissato ashift=9<\/code>. Se un amministratore di sistema esperto non modifica questa impostazione, questo SSD funziona pi\u00f9 lentamente<\/i> come un normale HDD magnetico.<\/p>\n

A confronto, per dimensioni troppo grandi ashift<\/code> non c\u2019\u00e8 praticamente alcuna penalizzazione. Non c'\u00e8 una reale riduzione delle prestazioni, e l'aumento dello spazio inutilizzato \u00e8 infinitesimale (o nullo con la compressione attivata). Pertanto, raccomandiamo vivamente anche a quei dischi che utilizzano effettivamente settori da 512 byte di impostare ashift=12<\/code> o addirittura ashift=13<\/code>, per guardare al futuro con fiducia.<\/p>\n

La propriet\u00e0 ashift<\/code> viene impostato per ogni dispositivo virtuale vdev, e non per il pool<\/i>, come molti erroneamente pensano - e non pu\u00f2 essere cambiato dopo l'impostazione. Se accidentalmente si sbaglia ashift<\/code> quando si aggiunge un nuovo vdev al pool, si \u00e8 contaminato irreparabilmente questo pool con un dispositivo a bassa prestazione e, in genere, non c'\u00e8 altra soluzione se non quella di distruggere il pool e ricominciare da capo. Anche rimuovere il vdev non salver\u00e0 da un'impostazione errata. ashift<\/code>!<\/p>\n

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

\n\"Fondamenti
\nSe un normale file system deve riscrivere i dati, cambia ogni blocco l\u00ec dove si trova.<\/i><\/p>\n

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

\"Fondamenti
\nIn termini astratti, ignorando la reale posizione fisica dei blocchi, la nostra \u00abcometa dei dati\u00bb si semplifica in un \u00abverme dei dati\u00bb 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 di copia alla scrittura: ogni blocco pu\u00f2 appartenere a pi\u00f9 snapshot e rester\u00e0 fino a quando non verranno distrutti 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 di base \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 \u00abva bene\u00bb \u2014 ma ti mentir\u00e0.<\/p>\n

Invece, il file system con copia alla scrittura salva una nuova versione del blocco modificato e poi aggiorna i metadati del file per interrompere il legame con il vecchio blocco e collegare a esso il nuovo blocco che hai appena scritto.<\/p>\n

La disconnessione del vecchio blocco e il collegamento del nuovo avviene in un'unica operazione, quindi non pu\u00f2 essere interrotta: se spegni l'alimentazione dopo che ci\u00f2 \u00e8 avvenuto, hai una nuova versione del file, e se spegni l'alimentazione prima, hai la vecchia versione. In entrambi i casi, non ci saranno conflitti nel file system.<\/p>\n

La copia alla scrittura in ZFS avviene non solo a livello di file system, ma anche a livello di gestione dei dischi. Questo significa che ZFS non \u00e8 soggetto a un buco nella scrittura (buco nel RAID<\/a><\/noindex>) \u2014 un fenomeno in cui il numero di strisce \u00e8 stato scritto solo parzialmente prima di un guasto di sistema, con danni all'array dopo il riavvio. Qui la striscia \u00e8 scritta in modo atomico, vdev \u00e8 sempre coerente, e Bob \u00e8 tuo zio.<\/a><\/noindex>.<\/p>\n

ZIL: diario delle intenzioni ZFS<\/h3>\n

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

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

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

\"Fondamenti
\nDopo un guasto, tutti i dati sporchi nel ZIL vengono ripristinati \u2013 in questo caso il ZIL si trova su SLOG, quindi vengono ripristinati proprio da l\u00ec<\/i><\/p>\n

Ci sono due categorie principali di operazioni di scrittura \u2013 sincroniche (sync) e asincroniche (async). Per la maggior parte dei carichi di lavoro, la stragrande maggioranza delle operazioni di scrittura \u00e8 asincronica \u2013 il file system consente di aggregarle e restituirle in pacchetti, riducendo la frammentazione e aumentando notevolmente la larghezza di banda.<\/p>\n

Le scritture sincroniche sono un'altra cosa. Quando un'applicazione richiede una scrittura sincronica, sta dicendo al file system: \u00abDevi confermarla nella memoria non volatile questo preciso momento<\/i>, e fino ad allora non posso fare nient'altro\u00bb. Pertanto, le scritture sincroniche devono essere immediatamente confermate su disco \u2013 e se ci\u00f2 aumenta la frammentazione o riduce la larghezza di banda, cos\u00ec sia.<\/p>\n

ZFS gestisce le scritture sincroniche in modo diverso rispetto ai normali file system \u2013 invece di riversarle immediatamente nello storage normale, ZFS le conferma in un'area di storage speciale chiamata journal delle intenzioni ZFS \u2013 ZFS Intent Log, o ZIL. La chiave \u00e8 che queste scritture anche<\/i> rimangono in memoria, aggregate insieme alle normali richieste di scrittura asincroniche, per essere successivamente scaricate nello storage come normali TXG (gruppi di transazione, Transaction Groups).<\/p>\n

In condizioni di funzionamento normale, il ZIL viene scritto e mai pi\u00f9 letto. Quando, dopo qualche istante, le scritture dal ZIL vengono confermate nello storage principale nei normali TXG dalla memoria, si scollegano 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 \u2013 guasto del sistema operativo o interruzione di corrente \u2013 quando ci sono dati nel ZIL, questi dati verranno letti durante il successivo import del pool (ad esempio, al riavvio del sistema di emergenza). Tutto ci\u00f2 che si trova nel ZIL sar\u00e0 letto, aggregato in gruppi TXG, confermato nello storage principale e poi scollegato dal ZIL durante il processo di importazione.<\/p>\n

Una delle classi ausiliarie vdev si chiama LOG o SLOG, dispositivo secondario LOG. Ha un compito: fornire un pool con un dispositivo vdev separato e, preferibilmente, molto pi\u00f9 veloce, con un'alta resilienza alla scrittura per memorizzare ZIL, invece di memorizzare ZIL nel principale archivio vdev. Lo stesso ZIL si comporta allo stesso modo indipendentemente dalla posizione di archiviazione, ma se un vdev con LOG ha una prestazione di scrittura molto alta, le scritture sincrone avranno luogo pi\u00f9 rapidamente.<\/p>\n

L'aggiunta di un vdev con LOG nel pool in alcun modo non pu\u00f2<\/b> migliorare le prestazioni della scrittura asincrona - anche se forzi tutte le scritture in ZIL tramite zfs set sync=always<\/code>, saranno comunque legate all'archiviazione principale in TXG allo stesso modo e alla stessa velocit\u00e0 di prima della registrazione. L'unico miglioramento diretto delle prestazioni \u00e8 il ritardo nella 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 gran numero di scritture sincrone, il vdev LOG pu\u00f2 indirettamente accelerare la scrittura asincrona e la lettura non memorizzata nella cache. Scaricare le scritture ZIL in un vdev LOG separato significa meno concorrenza per gli IOPS nello storage primario, il che migliora in qualche modo le prestazioni di tutte le operazioni di lettura e scrittura.<\/p>\n

Snapshot<\/h3>\n

\nIl meccanismo di copia-on-write \u00e8 anche una base necessaria per gli istantanei atomici di ZFS e la replica asincrona incrementale. In un file system attivo esiste un albero di puntatori che segna tutte le scritture con i dati correnti: quando si crea uno snapshot, si fa semplicemente una copia di questo albero di puntatori.<\/p>\n

Quando in un file system attivo viene sovrascritta una scrittura, ZFS prima scrive una nuova versione del blocco in uno spazio inutilizzato. Poi scollega la vecchia versione del blocco dal file system corrente. Ma se uno snapshot fa riferimento al vecchio blocco, rimane comunque immutato. Il vecchio blocco non sar\u00e0 effettivamente recuperato come spazio libero finch\u00e9 tutti gli snapshot che fanno riferimento a quel blocco non saranno eliminati!<\/p>\n

Replica<\/h3>\n

\n\"Fondamenti
\nLa mia libreria Steam nel 2015 occupava 158 GiB e conteneva 126.927 file. \u00c8 abbastanza vicino alla situazione ottimale per rsync: la replica di ZFS in rete era \"solo\" il 750% pi\u00f9 veloce.<\/i><\/p>\n

\"Fondamenti
\nNella stessa rete, la replica di un file immagine di macchina virtuale Windows 7 da 40 GiB \u00e8 un'altra storia. La replica ZFS avviene 289 volte pi\u00f9 velocemente rispetto a rsync \u2014 o 'solo' 161 volte pi\u00f9 veloce, se sei abbastanza esperto da chiamare rsync con l'opzione \u2014inplace.<\/i><\/p>\n

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

Una volta che capisci come funzionano gli snapshot, sar\u00e0 facile afferrare il concetto di replica. Poich\u00e9 uno snapshot \u00e8 semplicemente un albero di puntatori a registrazioni, ne consegue che se facciamo zfs send<\/code> di uno snapshot, stiamo inviando sia questo albero che tutte le registrazioni ad esso correlate. Quando trasmettiamo questo zfs send<\/code> in zfs receive<\/code> all'oggetto di destinazione, scrive sia il reale contenuto del blocco sia l'albero di puntatori che punta ai blocchi, nel set di dati di destinazione.<\/p>\n

Le cose diventano ancora pi\u00f9 interessanti con il secondo zfs send<\/code>. Ora abbiamo due sistemi, ciascuno dei quali contiene poolname\/datasetname@1<\/code>, e tu scatti un nuovo snapshot poolname\/datasetname@2<\/code>. Pertanto, nel pool sorgente hai datasetname@1<\/code> e datasetname@2<\/code>, mentre nel pool di destinazione hai solo il primo snapshot. datasetname@1<\/code>.<\/p>\n

Poich\u00e9 tra sorgente e destinazione abbiamo uno snapshot comune datasetname@1<\/code>, possiamo fare incrementale<\/i> zfs send<\/code> su di esso. Quando diciamo al sistema zfs send -i poolname\/datasetname@1 poolname\/datasetname@2<\/code>, confronta i due alberi di puntatori. Qualsiasi puntatore che esista solo in @2<\/code>, evidentemente, punta a nuovi blocchi - quindi avremo bisogno del contenuto di questi blocchi.<\/p>\n

Nel sistema remoto, l'elaborazione incrementale send<\/code> \u00e8 altrettanto semplice. Prima registriamo tutte le nuove registrazioni incluse nel flusso send<\/code>, e poi aggiungiamo i puntatori a questi blocchi. Voil\u00e0, abbiamo @2<\/code> nel nuovo sistema!<\/p>\n

La replica incrementale asincrona ZFS \u00e8 un enorme miglioramento rispetto ai metodi precedenti non basati su snapshot, come rsync. In entrambi i casi vengono trasferiti solo i dati modificati - ma rsync deve prima lettura<\/i> leggere i dati da entrambe le parti per verificare il checksum e confrontarlo. Al contrario, la replica ZFS non legge nulla tranne gli alberi di puntatori - e qualsiasi blocco che non \u00e8 presente nello snapshot comune.<\/p>\n

Compressione integrata<\/h3>\n

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

Se consideriamo un frammento di dati nel mezzo di un file, che inizia la sua vita come un megabyte di zeri da 0x00000000 e cos\u00ec via, \u00e8 molto facile comprimerlo in un solo settore su disco. Ma cosa succede se sostituiamo questo megabyte di zeri con un megabyte di dati non comprimibili, come JPEG o rumore pseudo-casuale? Improvvisamente, a questo megabyte di dati servirebbero non uno, ma 256 settori da 4 KiB, mentre in questa parte del disco \u00e8 riservato solo un settore.<\/p>\n

ZFS non ha questo problema, poich\u00e9 le registrazioni modificate vengono sempre scritte in spazio inutilizzato: il blocco originale occupa solo un settore da 4 KiB, mentre la nuova registrazione occuper\u00e0 256, ma questo non \u00e8 un problema: il frammento modificato pi\u00f9 recentemente \"dal mezzo\" del file sarebbe scritto nello spazio inutilizzato indipendentemente dal fatto che la sua dimensione sia cambiata o meno, quindi per ZFS \u00e8 una situazione del tutto normale.<\/p>\n

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

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