Ho provato a letto. Sebbene buono (e ha alcune utili funzioni differenziate che potrebbero renderlo la scelta migliore per molti), sembra scansionare tutti i file di destinazione per i checksum.
Che è dolorosamente lento.
Altri programmi, come rdfind e rmlint, scansionano in modo diverso.
rdfind ha una funzione "sperimentale" per l'utilizzo del reflink di btrfs. (E opzioni "solide" per hardlink, symlink, ecc.)
rmlint ha opzioni "solide" per clone di btrfs, reflink, hardlink regolari, symlink, delete e comandi personalizzati.
Ma soprattutto, rdfind e rmlint sono significativamente più veloci. Come in, ordini di grandezza. Invece di scansionare tutti i file di destinazione alla ricerca di checksum, fa questo, approssimativamente:
- Effettua la scansione dell'intero filesystem di destinazione, raccogliendo solo percorsi e dimensioni dei file.
- Rimuovi dalla considerazione i file con dimensioni file univoche. Solo questo, risparmia tempo e attività del disco. ("Scads" è una funzione esponenziale inversa o qualcosa del genere).
- Dei restanti candidati, scansionare i primi N byte. Rimuovi dalla considerazione quelli con dimensioni dello stesso file ma primi N byte diversi.
- Fare lo stesso per gli ultimi N byte.
- Rimane solo quella (di solito una piccola frazione), alla ricerca di checksum.
Altri vantaggi di rmlint di cui sono a conoscenza:
- È possibile specificare il checksum. md5 troppo spaventoso? Prova sha256. O 512. O confronto bit per bit. O la tua funzione di hashing.
- Ti dà l'opzione di "clone" di Btrfs e "reflink", piuttosto che semplicemente reflink. "cp --reflink = always" è solo un po 'rischioso, in quanto non è atomico, non è a conoscenza di cos'altro sta succedendo per quel file nel kernel e non conserva sempre i metadati. "Clone", OTOH (che è un termine abbreviato ... Sto cancellando il nome ufficiale correlato all'API), è una chiamata a livello di kernel atomica che conserva i metadati. Quasi sempre con lo stesso risultato, ma un po 'più robusto e sicuro. (Sebbene la maggior parte dei programmi sia abbastanza intelligente da non eliminare il file duplicato, se prima non riesce a far riflettere con successo un temp sull'altro.)
- Ha un sacco di opzioni per molti casi d'uso (che è anche uno svantaggio).
Ho confrontato rmlint con deduperemove, che esegue anche una scansione alla cieca di tutti i file di destinazione alla ricerca di checksum. Duperemove ha impiegato diversi giorni per completare il mio volume (4 credo), andando al massimo. fmlint ha impiegato alcune ore per identificare i duplicati, quindi meno di un giorno per dedurli con il clone di Btrfs.
(Detto questo, chiunque si stia impegnando per scrivere e supportare software di qualità, robusto e distribuire gratuitamente, merita grandi complimenti!)
A proposito: dovresti evitare il deduping usando i normali hardlink come soluzione "generale" di dedup, a tutti i costi.
Sebbene i collegamenti fisici possano essere estremamente utili in alcuni casi d'uso mirati (ad esempio singoli file o con uno strumento in grado di eseguire la scansione per tipi di file specifici che superano una dimensione minima o come parte di molte soluzioni di backup / istantanee gratuite e commerciali), può essere disastroso per "deduplicazione" su un grande filesystem di uso generale. Il motivo è che la maggior parte degli utenti può avere migliaia di file nel proprio filesystem, che sono binari identici, ma funzionalmente completamente diversi.
Ad esempio, molti programmi generano file di modello e / o impostazioni nascoste (a volte in ogni singola cartella che può vedere), che inizialmente sono identici - e la maggior parte rimane tale, finché l'utente, l'utente, non ne ha bisogno.
Come illustrazione specifica: i file di cache delle miniature delle foto, che innumerevoli programmi generano nella cartella contenente le foto (e per una buona ragione - portabilità), possono richiedere ore o giorni per essere generati, ma poi rendere l'utilizzo di un'app per foto un gioco da ragazzi. Se quei file di cache iniziali sono tutti collegati tramite hardlink, quindi apri l'app in una directory e crea una cache di grandi dimensioni ... quindi indovina un po ': Ora OGNI cartella che ha una cache con hardlink precedente, ora ha la cache sbagliata. Potenzialmente, con risultati disastrosi che possono causare la distruzione accidentale dei dati. E anche potenzialmente in un modo che esplode una soluzione di backup che non è a conoscenza del collegamento fisico.
Inoltre, può rovinare intere istantanee. L'intero punto delle istantanee è che la versione "live" può continuare a cambiare, con la possibilità di tornare a uno stato precedente. Se tutto è strettamente collegato insieme però ... "rollback" alla stessa cosa.
La buona notizia però è che il deduping con clone / reflink di Btrfs può annullare quel danno (penso - dato che durante la scansione, dovrebbe vedere i file hardlinked identici ... a meno che non abbia una logica per non considerare i hardlink. Probabilmente dipende da l'utilità specifica che esegue il deduping.)