C'è un modo per creare copie di mucche in ZFS?

Sto cercando di creare copie di mucca di alcuni file / directory, ma dei vari modi che conosco sembrano tutti non ottimali.

Ad esempio, btrfs può, con l'uso di cp --reflink=autogenerare rapidamente copie di file mucca.

Cosa ho provato:

1. Symlink: non va bene. File rinominato, collegamento interrotto.
2. Hardlink: meglio, ma ancora non va bene. Le modifiche a un file cambieranno l'altro e non voglio necessariamente cambiare l'altro file.
3. Crea un'istantanea del set di dati, quindi clona l'istantanea: può funzionare, ma non bene. Spesso non cerco una copia dell'intero set di dati o che le copie si comportino come un altro set di dati. Poi ci sono le relazioni genitore / figlio tra il clone / istantanea / originale, che a quanto ho capito sono difficili, se non impossibili da interrompere.
4. Utilizzando zfs send/receivee abilitato il dedup, replicare il set di dati in un nuovo set di dati: questo evita le relazioni padre / figlio sull'uso di un clone, ma crea ancora inutilmente un altro set di dati e soffre ancora della lentezza implicita nei file che devono essere letti al 100% e i blocchi referenziati di nuovo invece che scritti.
5. Copia i file e lascia che il dedup faccia il suo lavoro: funziona, ma è lento perché i file devono essere letti al 100% e quindi fare nuovamente riferimento ai blocchi invece di scrivere.

La lentezza dell'invio / ricezione di zfs e la copia fisica o rsyncing sono ulteriormente esacerbate perché la maggior parte delle cose sono archiviate compresse e devono essere decompresse durante la lettura, quindi compresse prima che il dedup entri in azione per fare riferimento ai blocchi duplicati.

In tutte le mie ricerche, non sono stato in grado di trovare nulla di simile alla semplicità di --reflink in btrfs da remoto.

Quindi, c'è un modo per creare copie di mucche in ZFS? Oppure la copia "fisica" e il deduping fanno del suo lavoro l'unica vera opzione?

Penso che l'opzione 3 come hai descritto sopra sia probabilmente la soluzione migliore. Il problema più grande con quello che vuoi è che ZFS gestisce davvero solo questo copy-on-write a livello di set di dati / istantanea.

Consiglio vivamente di evitare di usare il dedup a meno che tu non abbia verificato che funzioni bene con il tuo ambiente esatto. Ho un'esperienza personale con il dedup che funziona alla grande fino a quando non viene spostato un altro utente o un archivio VM, quindi cade da un picco di prestazioni e causa molti problemi. Solo perché sembra che funzioni perfettamente con i tuoi primi dieci utenti, la tua macchina potrebbe cadere quando aggiungi l'undicesimo (o dodicesimo, o tredicesimo o altro). Se vuoi seguire questa strada, assicurati assolutamente di avere un ambiente di test che imiti esattamente l'ambiente di produzione e che funzioni bene in quell'ambiente.

Tornando all'opzione 3, dovrai impostare un set di dati specifico per contenere ciascuno degli alberi del file system che vuoi gestire in questo modo. Dopo averlo configurato e popolato inizialmente, scatta le tue istantanee (una per set di dati che differirà leggermente) e promuovile quindi in cloni. Non toccare mai più il set di dati originale.

Sì, questa soluzione ha problemi. Non sto dicendo che non lo sia, ma date le restrizioni di ZFS, è probabilmente il migliore. Ho trovato questo riferimento a qualcuno che utilizza i cloni in modo efficace: http://thegreyblog.blogspot.com/2009/05/sparing-disk-space-with-zfs-clones.html

Non ho molta familiarità con btrfs, ma se supporta le opzioni desiderate, hai pensato di configurare un server separato solo per supportare questi set di dati, usando Linux e btrfs su quel server?

L'opzione 5 è la migliore.

Per quanto riguarda i set di dati padre / figlio nell'opzione 3, è possibile promuovere un clone e non sarà più figlio del set di dati clonato. Non utilizzerà ancora blocchi extra. Modifica: notato che questo inverte solo la relazione padre / figlio, non la distrugge.

Per quanto riguarda le cose che vengono compresse / crittografate e che rallentano la copia, è completamente falso. Il tuo processore è molto più veloce del tuo dispositivo a blocchi (anche se usi SSD). Solo per alcuni numeri di esempio, diciamo che ci vogliono 10 secondi per leggere un blocco, ma ci vuole solo un secondo per decomprimerlo e 2 secondi per decrittografarlo. Il blocco 1 viene letto in 10 secondi e inviato alla CPU. La CPU inizia a decomprimere e decrittografare mentre il disco inizia a leggere il blocco 2. La CPU completerà il suo compito in 3 secondi e trascorrerà i successivi 7 secondi in attesa sul disco. Nel frattempo il disco ha impiegato lo stesso tempo a leggere quei due blocchi (20 secondi) indipendentemente dal fatto che i blocchi siano compressi o meno.

Allo stesso modo durante la scrittura, viene ritardato solo il primo blocco. La CPU comprime / crittografa il blocco 1 e lo invia al disco. Mentre il disco scrive il blocco 1, la CPU inizierà a comprimere / crittografare i blocchi successivi. La CPU masticherà i blocchi molto più velocemente di quanto il disco possa scriverli, quindi non è un problema. (Sì, è più complesso di così, ma questa è la sostanza.)

Ci scusiamo per la spiegazione troppo lunga di un punto minore della tua domanda, ma volevo chiarire questo malinteso.