Forza l'aggiornamento di checksum su zfs?

Di recente ho modificato la checksumproprietà su uno dei miei filesystem zfs non duplicati su sha256da on(fletcher4) per supportare meglio l'invio di flussi di replica duplicati, come in questo comando zfs send -DR -I _starting-snaphot_ _ending-snapshot_.

Tuttavia, la manpage di zfs ha questo da dire su send -D:

Questo flag può essere utilizzato indipendentemente dalla proprietà di dedup del set di dati, ma le prestazioni saranno molto migliori se il filesystem utilizza un checksum abilitato al dedup (ad es. Sha256).

La manpage zfs afferma anche questo sulla checksumproprietà:

La modifica di questa proprietà influisce solo sui dati appena scritti.

Non desidero fidarmi di fletcher4. Il compromesso è che a differenza di SHA256, fletcher4 non è una funzione hash pseudo-casuale, e quindi non ci si può fidare di non scontrarsi. È quindi adatto solo per il dedup quando combinato con l'opzione 'verifica', che rileva e risolve le collisioni di hash.

Come posso aggiornare i checksum del filesystem, preferibilmente senza delineare il sistema?

zfs zfsonlinux

— 84104
fonte

Per modificare le proprietà (che si tratti di compressione, deduplicazione o checksum) di dati già scritti, l'approccio zfs consiste nell'eseguire i dati attraverso una zfs send | zfs receivesequenza. Ovviamente, non è necessario disconnettere il sistema per quello, ma sarà necessario

risorse sufficienti nel tuo zpool / sul sistema per contenere due copie deduplicate del set di dati in questione
i tempi di inattività del set di dati in quanto è necessario distruggerlo o rinominarlo nella procedura
abbastanza tempo e pazienza per completare l'operazione

Dato che stai già utilizzando la deduplicazione per zpool, eseguendo un zfs send | zfs receivecon la destinazione sullo stesso pool dell'origine utilizzerebbe solo lo spazio necessario per i blocchi di metadati appena scritti. Preparati al tempo necessario per la copia: il dedup può essere terribilmente lento, soprattutto se non hai abbastanza RAM per contenere l'intera tabella di dedup nella RAM.

Dovresti assolutamente interrompere tutte le operazioni di scrittura per creare la copia finale e autorevole del set di dati, ma potresti ridurre al minimo i tempi di inattività copiando prima uno snapshot, interrompendo tutte le scritture e facendo incrementale zfs send -i | zfs receivecome passaggio finale.

— the-Wabbit
fonte

Non mi è affatto chiaro che zfs receiveaggiorni i metadati di un filesystem. Mi sembra che sarebbe molto più veloce se prendesse semplicemente i metadati così come sono. Tuttavia, ciò potrebbe essere impossibile a causa del blocco del checksum, piuttosto che della natura del livello del file. In tal caso zfs send | zfs receivecostituirebbe una base accettabile per una soluzione.

— 84104,

zfs invia | zfs recv cambierà efficacemente tutti i metadati (scelta di compressione, scelta di checksum, scelta di dedup). zfs send sta creando un oggetto che poi ingerisci usando zfs recv, che lo scrive praticamente come se fossero tutti nuovi dati. Tuttavia, penso che potresti avere un'idea sbagliata di zfs send | recv in merito alla deduplicazione. zfs send -D tenta di eseguire la deduplicazione dei dati / all'interno del flusso stesso /, non di mantenere la deduplicazione esistente dei dati dal set di dati di origine. Questo è il motivo per cui non è necessario che anche il lato recv abbia abilitato il dedup sul set di dati di destinazione.

— Nex7,

Per spiegare ulteriormente: al momento non è possibile inviare dati deduplicati zfs in modo tale che tutto ciò che passa attraverso il cavo sia una singola copia dei dati deduplicati e delle voci della tabella di dedupe associate. Nemmeno se l'origine e la destinazione sono sincronizzate e non stai inviando altro che uno snapshot incrementale. ZFS mantiene comunque i dati di invio a dimensione intera se i dati al suo interno risultano non deduplicabili / nell'ambito del flusso stesso /. Potresti avere dati facilmente deducibili nel DDT POOL, ma come un piccolo oggetto di invio, essere completamente non deduplicabile.

— Nex7,