Ich habe versucht, mich zu betten. Obwohl es gut ist (und einige nützliche, differenzierte Funktionen aufweist, die es für viele zur besten Wahl machen können), scheint es die Gesamtheit aller Zieldateien nach Prüfsummen zu durchsuchen.
Welches ist schmerzhaft langsam.
Andere Programme wie rdfind und rmlint scannen dagegen anders.
rdfind hat eine "experimentelle" Funktion zur Verwendung von btrfs reflink. (Und "solide" Optionen für Hardlinks, Symlinks usw.)
rmlint bietet "solide" Optionen für btrfs-Klonen, Reflink, reguläre Hardlinks, Symlinks, Löschen und Ihre eigenen benutzerdefinierten Befehle.
Noch wichtiger ist jedoch, dass rdfind und rmlint erheblich schneller sind. Wie in Größenordnungen. Anstatt alle Zieldateien nach Prüfsummen zu durchsuchen, geschieht dies ungefähr:
- Scannen Sie das gesamte Zieldateisystem und erfassen Sie nur Pfade und Dateigrößen.
- Entfernen Sie Dateien mit eindeutigen Dateigrößen aus der Betrachtung. Dies allein spart viel Zeit und Festplattenaktivität. ("Scads" ist eine inverse Exponentialfunktion oder so.)
- Scannen Sie von den verbleibenden Kandidaten die ersten N Bytes. Entfernen Sie aus der Betrachtung diejenigen mit den gleichen Dateigrößen, aber unterschiedlichen ersten N Bytes.
- Machen Sie dasselbe für die letzten N Bytes.
- Nur von diesem (normalerweise winzigen Bruchteil) Rest, suchen Sie nach Prüfsummen.
Weitere Vorteile von rmlint sind mir bekannt:
- Sie können die Prüfsumme angeben. md5 zu gruselig? Versuchen Sie es mit sha256. Oder 512. Oder Bit für Bit-Vergleich. Oder Ihre eigene Hashing-Funktion.
- Sie haben die Möglichkeit, Btrfs "zu klonen" und "neu zu verknüpfen", anstatt nur neu zu verknüpfen. "cp --reflink = always" ist nur ein bisschen riskant, da es nicht atomar ist, nicht weiß, was sonst noch für diese Datei im Kernel vor sich geht, und Metadaten nicht immer erhalten bleiben. "Clone", OTOH (eine Abkürzung ... Ich habe den offiziellen API-bezogenen Namen ausgeblendet), ist ein Aufruf auf Kernel-Ebene, der atomar ist und Metadaten beibehält. Fast immer ergibt sich das Gleiche, aber ein bisschen robuster und sicherer. (Obwohl die meisten Programme intelligent genug sind, um die doppelte Datei nicht zu löschen, kann ein temporärer Reflink zum anderen nicht erfolgreich durchgeführt werden.)
- Es gibt eine Menge Optionen für viele Anwendungsfälle (was auch ein Nachteil ist).
Ich habe rmlint mit deduperemove verglichen, das auch blind alle Zieldateien nach Prüfsummen durchsucht. Duperemove brauchte mehrere Tage, um mein Volumen zu vervollständigen (4, glaube ich), und ging auf Hochtouren . fmlint brauchte einige Stunden , um Duplikate zu identifizieren, und dann weniger als einen Tag, um sie mit dem Btrfs-Klon zu dedupieren.
(Das heißt, jeder, der sich die Mühe macht, qualitativ hochwertige, robuste Software zu schreiben und zu unterstützen und sie kostenlos zu verschenken, verdient ein großes Lob!)
Übrigens: Sie sollten um jeden Preis vermeiden, Deduping mit regulären Hardlinks als "allgemeine" Dedup-Lösung durchzuführen.
Während Hardlinks in bestimmten gezielten Anwendungsfällen äußerst praktisch sein können (z. B. einzelne Dateien oder mit einem Tool, das nach bestimmten Dateitypen suchen kann, die eine Mindestgröße überschreiten - oder als Teil vieler kostenloser und kommerzieller Backup- / Snapshot-Lösungen), kann dies katastrophal sein für "Deduplizierung" auf einem großen allgemein verwendeten Dateisystem. Der Grund dafür ist, dass die meisten Benutzer möglicherweise Tausende von Dateien in ihrem Dateisystem haben, die binär identisch, aber funktional völlig unterschiedlich sind.
Beispielsweise generieren viele Programme Vorlagen- und / oder versteckte Einstellungsdateien (manchmal in jedem einzelnen Ordner, den sie sehen können), die anfangs identisch sind - und die meisten bleiben so, bis Sie als Benutzer dies nicht benötigen.
Zur Veranschaulichung: Die Erstellung von Miniatur-Cache-Dateien für Fotos, die unzählige Programme in dem Ordner mit den Fotos generieren (und das aus gutem Grund - Portabilität), kann Stunden oder Tage dauern, aber die Verwendung einer Foto-App ist ein Kinderspiel. Wenn diese anfänglichen Cache-Dateien alle fest miteinander verknüpft sind, öffnen Sie die App später in einem Verzeichnis und es wird ein großer Cache erstellt. Dann raten Sie mal: Jetzt hat JEDER Ordner, der einen zuvor fest verknüpften Cache hat, jetzt den falschen Cache. Möglicherweise mit katastrophalen Folgen, die zu einer versehentlichen Datenvernichtung führen können. Und möglicherweise auch so, dass eine Backup-Lösung explodiert, die nicht über Hardlinks informiert ist.
Darüber hinaus können ganze Schnappschüsse ruiniert werden. Der springende Punkt bei Schnappschüssen ist, dass sich die "Live" -Version weiter ändern kann und ein Rollback auf einen vorherigen Status möglich ist. Wenn jedoch alles fest miteinander verbunden ist, "rollen" Sie auf dasselbe zurück.
Die gute Nachricht ist jedoch, dass das Dedupieren mit Btrfs-Klon / -Reflink diesen Schaden rückgängig machen kann (ich denke - da während des Scans fest verknüpfte Dateien als identisch angezeigt werden sollten ... es sei denn, es hat Logik, Hardlinks nicht zu berücksichtigen. Dies hängt wahrscheinlich davon ab das spezifische Dienstprogramm, das die Dedupierung durchführt.)