La tua domanda è un po 'confusa a causa del termine "blocchi", che è una parola molto sovraccarica quando si tratta di dischi e filesystem. (Ma il contesto circostante aiuta a chiarire.) Btrfs non si occupa di "blocchi" di file system di dimensioni fisse, ma di "estensioni" di dimensioni variabili. (Anche se, confusamente, definisce anche zone di blocco di dimensioni variabili.) ZFS si occupa dei "blocchi" del filesystem, in parte o principalmente perché farlo presenta problemi significativamente più facili da risolvere. Sia Btrfs che ZFS sono a conoscenza dei "blocchi" a livello del disco, che sono essi stessi astrazioni. (Quindi abbiamo anche "archiviazione a livello di blocco", che può essere un significato semanticamente diverso.) Potrei avere quelle descrizioni un po 'fuori, non abbastanza chiare o non accurate al 100%. (Se hai bisogno di chiarezza e precisione al 100% sull'argomento dei blocchi, far finta di non averlo letto. Se hai solo bisogno di una comprensione approssimativa per continuare, allora dovresti essere bravo ad andare.) Il punto principale di questa risposta non è definire perfettamente i "blocchi", ma la discussione che segue, che è molto più nella mia timoniera.
Come ha scritto @killermist, ZFS supporta nativamente la deduplicazione a livello di blocco [ZFS].
Non è abilitato per impostazione predefinita in ZFS. L'accensione senza memoria sufficiente comporta un forte impatto sulle prestazioni. Inoltre, aneddoticamente, ZFS ha bisogno di una discreta quantità in più rispetto alla regola empirica consigliata da "1 GB di RAM per 1 TB di memoria", per adattarsi all'intero hashtable nella RAM. Tuttavia, a seconda dell'hardware è ancora possibile ottenere velocità di scrittura superiori a 40 MB / s. Lo capisco su tecnologia dell'era del 2008 con unità dell'era del 2015. Perfettamente accettabile per me per la maggior parte dei dati d'archivio. Il più grande svantaggio della deduplicazione ZFS è che non esiste ancora un modo elegante per farlo in modalità "batch / offline" (o più precisamente "fuori banda"), oltre all'attivazione del dedup, copiando tutto in un nuova directory temporanea sullo stesso filesystem, eliminando gli originali, quindi spostando indietro i contenuti temporanei (ora deduplicati).
La deduplicazione di Btrfs è probabilmente un po 'più complicata, con solo utility di terze parti attualmente disponibili per fare il lavoro. (Ma che usano API del kernel ben supportate e / o un'opzione ben supportata per cp; e in entrambi i casi che richiedono la propria logica per determinare i duplicati, che si spera sia assolutamente accurato.) Un potenziale vantaggio però sono quelle utilità sono "fuori banda". Il costo per la maggior parte delle utility, tuttavia, è che uccidono le prestazioni mentre martellano via, il che può richiedere ore, giorni, persino settimane per essere completato. (Personalmente preferirei gestire prestazioni di scrittura sempre più lente della deduplicazione ZFS in-band, piuttosto che martellare i miei HDD per giorni, diciamo, finiscono una volta all'anno.)
Sono a conoscenza di due soluzioni Btrfs che riguardano i "blocchi" (ma in ancora un'altra definizione) piuttosto che i file, sono api e dduper .
Le api, ad esempio, definiscono arbitrariamente una dimensione di "blocco" per sé al primo avvio, in base alla memoria disponibile e forse ad altri fattori. (Anche se probabilmente sto travisando il suo scopo, le sue caratteristiche, il suo meccanismo e i suoi pro / contro, dal momento che non lo uso, l'ho valutato solo di recente come un'opzione.)
Le api sono probabilmente leggermente ibride, poiché sono progettate per funzionare ininterrottamente e non martellare i dischi così duramente, anche se non è ancora tecnicamente "in-band" come il dedup ZFS. Raccoglie semplicemente i duplicati dopo il fatto e cerca di deduplicarli con un leggero tocco. Lavorare con una dimensione di blocco definita arbitrariamente significa che, in base alla progettazione, si adatterà alla tabella hash nella RAM. Lo svantaggio (presumibilmente) è che in un "blocco" potrebbero esserci delle estensioni uguali, ma le API potrebbero non dedurle perché i "blocchi" in cui si trovano sono altrimenti diversi.
Tieni presente che anche i programmi di utilità che eseguono in modo specifico la deduplicazione Btrfs di livello "file" (come bedup , duperemove , rmlint e altri), potrebbero comunque soddisfare le tue esigenze. Non posso esserne sicuro, ma sembra che lo farebbero. Questo perché anche un comando "cp --reflink = always" non sta realmente deduplicando "file". Dedica le estensioni di Btrfs . Quando un "file" riflesso cambia, Btrfs non deduplica solo le estensioni che cambiano, nelle loro estensioni uniche. Il resto del file rimane deduplicato. Ecco come i file deduplicati di grandi dimensioni possono ancora divergere come se fossero i propri file univoci, ma essere comunque per lo più deduplicati.
(Questo è anche il motivo per cui è così difficile determinare se un "file" è riflesso o meno, perché quel concetto non ha nemmeno davvero senso. Tutte le estensioni di un file possono esse stesse essere riflesse ad altri uguali, un concetto che fa ha senso, ma per coincidenza è una domanda particolarmente difficile a cui rispondere. Ecco perché, a meno che un'utilità di deduplicazione Btrfs non tenga traccia di ciò che ha già deduplicato, non vale la pena tentare di "rilevare" se un file è già stato deduplicato. Non esiste alcun attributo come refcount da ispezionare. È comunque più semplice deduplicarlo di nuovo comunque. Al contrario, determinare se un intero file è hardlink nel vecchio stile, è banale. Basta controllare il conteggio st_nlink per un dato inode.)
La mancanza di un "intero clone di file" è in effetti una caratteristica intrinseca di tutti i filesystem CoW che supportano istantanee e / o deduplicazione "libere", ed è vero sia che si tratti di estensioni di Btrfs, blocchi ZFS o qualcos'altro. Ecco perché uno dei due può probabilmente essere una risposta alla tua domanda. (Esistono almeno altri tre filesystem CoW che possono o sono in programma di essere in grado di fare tutto ciò di cui sono a conoscenza: nilfs2, bcachefs e xfs.)
Anche se non lo hai menzionato, nessuna tecnologia di deduplicazione a mia conoscenza, è consapevole del tipo di file. In altre parole, nessun deduplicatore sa ignorare i metadati * .jpg e considerare solo i dati di immagine compressi per la deduplicazione. Allo stesso modo, nessuno di loro considera i numeri magici dei file (almeno per determinare cosa considerare per la deduplicazione). Potrebbe essere una caratteristica killer, anche se sicuramente richiede aggiornamenti costanti e costanti delle definizioni. E potrebbe essere davvero difficile da progettare, trattando al contempo i file come una raccolta M: M astratta di estensioni, blocchi, ecc.