Welche Lösungen gibt es für die Deduplizierung auf Blockebene oder für eine detailliertere Deduplizierung?
Es gibt dateibasierte – mit „Copy-On-Write“-Ansatz.
Ich suche nach „Copy-on-Write“ auf Blockebene, damit ich regelmäßig nach gemeinsamen Blöcken oder – vorzugsweise – Dateiteilen suchen, sie zusammenführen und für die CoW-Verwendung markieren kann. Gibt es so etwas schon oder muss es noch erstellt werden? Ich bin nicht sicher, ob die Btrfs-Deduplizierung auf Block-/Datei-/Unterteilebene erfolgt? Es gibt LessFS, aber ich bin nicht sicher, welche Deduplizierungsebene es bietet? Vielleicht eine andere Lösung?
Antwort1
Was die Deduplizierung auf Blockebene angeht, ist ZFS meiner Meinung nach derzeit die unbestritten beste Implementierung. Es ist nicht wirklich für eine nachträgliche Optimierung ausgelegt, da die Deduplizierung (sofern aktiviert) direkt in die Lese-/Schreibfunktionen integriert ist. Aus diesem Grund kann es unter Last etwas speicherintensiv sein, wenn versucht wird, die relevantesten Teile der Deduplizierungstabelle im Speicher zu behalten. ZFS ist jedoch gut darin, sich darauf zu beschränken, nicht viel mehr als 50 % des Speichers zu verbrauchen, was je nach installierter Speichermenge ziemlich willkürlich erscheinen kann (50 % von 2 GB gegenüber 50 % von 64 GB, insbesondere wenn nur wenige oder gar keine Benutzeraufgaben Speicher benötigen).
Je nachdem, wofür Sie es verwenden möchten, stehen Ihnen einige Optionen zur Verfügung:
OffenIndianascheint einige gute Desktop- und Server-Optionen zu haben, basierend auf Solaris
FreeBSD (seit 9.0) hat eine ziemlich fortgeschrittene Version von ZFS (einschließlich Deduplizierung) eingebaut. Eine bemerkenswerte von FreeBSD (damals MonoWall) abgeleitete Distribution istNAS4Free, was die Erstellung eines NAS ziemlich einfach macht.
Linux bietet einige Optionen, einige mit Deduplizierung, andere ohne. Da Sie nach Deduplizierung suchen, ist die bemerkenswerteste, die ich gesehen habe,zfsonlinux. Ich bin mir nicht sicher, wie weit sie sind oder wie stabil ihr Projekt ist, aber es sieht auf jeden Fall vielversprechend aus.
Was die teilweise Blockdeduplizierung betrifft, habe ich bisher NICHTS gesehen, das von einer entsprechenden Möglichkeit berichtet.
Antwort2
Ihre Frage ist aufgrund des Begriffs „Blöcke“, der in Bezug auf Festplatten und Dateisysteme ein sehr überladenes Wort ist, ein wenig verwirrend. (Aber Ihr umgebender Kontext hilft bei der Klärung.) Btrfs befasst sich nicht mit Dateisystem-„Blöcken“ fester Größe, sondern mit „Bereichen“ variabler Größe. (Definiert jedoch verwirrenderweise auch Blockzonen variabler Größe.) ZFS befasst sich mit Dateisystem-„Blöcken“, teilweise oder hauptsächlich, weil dies wesentlich einfacher zu lösende Probleme mit sich bringt. Sowohl Btrfs als auch ZFS kennen „Blöcke“ auf Festplattenebene, die selbst Abstraktionen sind. (Dann haben wir auch „Speicher auf Blockebene“, was eine semantisch andere Bedeutung haben kann.) Ich habe diese Beschreibungen möglicherweise ein wenig falsch verstanden, sie sind nicht klar genug oder nicht 100 % genau. (Wenn Sie Klarheit und 100 % Genauigkeit zum Thema Blöcke benötigen, tun Sie so, als hätten Sie das nicht gelesen. Wenn Sie nur ein grobes Verständnis brauchen, um weiterzumachen, sollte es kein Problem sein.) Der Hauptpunkt dieser Antwort ist nicht die perfekte Definition von „Blöcken“, sondern die folgende Diskussion, die viel mehr in meinem Aufgabenbereich liegt.
Wie @killermist schrieb, unterstützt ZFS nativ die Deduplizierung auf Blockebene [ZFS].
Es ist in ZFS nicht standardmäßig aktiviert. Wenn es ohne ausreichend Speicher aktiviert wird, führt dies zu erheblichen Leistungseinbußen. Außerdem benötigt ZFS, wie anekdotisch berichtet wird, deutlich mehr als die empfohlene Faustregel „1 GB RAM pro 1 TB Speicher“, um die gesamte Hashtabelle in den RAM zu packen. Aber selbst dann können Sie je nach Hardware immer noch Schreibgeschwindigkeiten von über 40 MB/s erreichen. Ich erreiche das mit Technologie aus dem Jahr 2008, die auf Laufwerken aus dem Jahr 2015 läuft. Für mich vollkommen akzeptabel für hauptsächlich Archivdaten. Der größte Nachteil der ZFS-Deduplizierung ist, dass es noch keine elegante Möglichkeit gibt, dies im „Batch/Offline“-Modus (oder genauer „Out-of-Band“) durchzuführen, außer die Deduplizierung zu aktivieren, alles in ein neues temporäres Verzeichnis auf demselben Dateisystem zu kopieren, die Originale zu löschen und dann die (jetzt deduplizierten) temporären Inhalte zurück zu verschieben. (Außer dass das Löschen der alten Dateien länger dauern kann als der anfängliche Kopier-/Deduplizierungsvorgang.) Normalerweise warte ich, bis ich das Array ohnehin regelmäßig neu strukturieren muss, um das grundlegende Layout zu ändern, und kopiere dann mit aktivierter Deduplizierung vom alten in das neue Array.
Die Btrfs-Deduplizierung ist wohl etwas lückenhafter, da derzeit nur Dienstprogramme von Drittanbietern für diese Aufgabe verfügbar sind. (Die jedoch entweder gut unterstützte Kernel-APIs und/oder eine gut unterstützte Option für cp verwenden und in jedem Fall ihre eigene Logik zur Ermittlung von Duplikaten benötigen, von der man hofft, dass sie absolut genau ist.) Ein potenzieller Vorteil besteht jedoch darin, dass diese Dienstprogramme „out-of-band“ sind. Der Preis für die meisten Dienstprogramme besteht jedoch darin, dass sie die Leistung beeinträchtigen, während sie weiterarbeiten – was Stunden, Tage oder sogar Wochen dauern kann. (Persönlich würde ich mich lieber mit der immer langsameren Schreibleistung der In-Band-ZFS-Deduplizierung abfinden, als meine Festplatten beispielsweise einmal im Jahr tagelang zu belasten.)
Zwei mir bekannte Btrfs-Lösungen, die sich mit "Blöcken" (aber in einer anderen Definition) statt mit Dateien befassen, sindBienen, UndAbonnieren.
Bees beispielsweise definiert beim ersten Ausführen willkürlich eine „Block“-Größe für sich selbst, basierend auf dem verfügbaren Speicher und möglicherweise anderen Faktoren. (Obwohl ich seinen Zweck, seine Funktionen, seinen Mechanismus und seine Vor- und Nachteile wahrscheinlich falsch darstelle, da ich es nicht verwende, habe ich es erst kürzlich als Option bewertet.)
Bees ist wohl ein wenig hybrid, da es für den Dauerbetrieb konzipiert ist und die Festplatten nicht ganz so stark beansprucht – obwohl es technisch gesehen immer noch nicht „in-band“ ist wie die ZFS-Deduplizierung. Es erkennt Duplikate einfach nachträglich und versucht, sie mit sanfter Berührung zu deduplizieren. Das Arbeiten mit einer beliebig definierten Blockgröße bedeutet, dass die Hashtabelle konstruktionsbedingt in den RAM passt. Der Nachteil (vermutlich) ist, dass es in einem „Block“ möglicherweise gleiche Extents gibt, Bees jedoch möglicherweise keine Deduplizierung durchführt, da die „Blöcke“, in denen sie sich befinden, ansonsten unterschiedlich sind.
Beachten Sie, dass selbst Dienstprogramme, die speziell Btrfs-Deduplizierung auf Dateiebene durchführen (wieBett,Abonnieren,rmlintund andere), können Ihre Anforderungen dennoch erfüllen. Ich kann es nicht mit Sicherheit sagen, aber es scheint, als würden sie es tun. Das liegt daran, dass selbst ein „cp --reflink=always“-Befehl nicht wirklich „Dateien“ dedupliziert. Er dedupliziert BtrfsAusmaße. Wenn sich eine neu verknüpfte „Datei“ ändert, entfernt Btrfs nur die Duplikate der geänderten Bereiche in ihre eigenen, einzigartigen Bereiche. Der Rest der Datei bleibt dedupliziert. So können große deduplizierte Dateien immer noch voneinander abweichen, als wären sie ihre eigenen, einzigartigen Dateien, aber dennoch größtenteils dedupliziert sein.
(Das ist auch der Grund, warum es so schwierig ist, festzustellen, ob eine „Datei“ neu verknüpft ist oder nicht, denn dieses Konzept ergibt nicht einmal wirklich Sinn. AlleAusmaßekönnen selbst mit anderen gleichen Extents neu verknüpft werden, ein Konzept, das durchaus Sinn macht, aber zufälligerweise eine besonders schwer zu beantwortende Frage ist. Aus diesem Grund lohnt es sich nicht, zu versuchen, „festzustellen“, ob eine Datei bereits dedupliziert wurde, es sei denn, ein Btrfs-Deduplizierungsprogramm verfolgt, was es bereits dedupliziert hat. Es gibt kein Attribut wie refcount, das überprüft werden könnte. Es ist sowieso einfacher, es einfach erneut zu deduplizieren. Im Gegensatz dazu ist es trivial, festzustellen, ob eine ganze Datei auf die altmodische Weise fest verknüpft ist. Überprüfen Sie einfach die st_nlink-Anzahl für einen bestimmten Inode.)
Das Fehlen eines „vollständigen Dateiklons“ ist tatsächlich ein inhärentes Merkmal aller CoW-Dateisysteme, die „kostenlose“ Snapshots und/oder Deduplizierung unterstützen, und gilt unabhängig davon, ob es sich um Btrfs-Extents, ZFS-Blöcke oder etwas anderes handelt. Deshalb kann wahrscheinlich jedes von beiden eine Antwort auf Ihre Frage sein. (Es gibt mindestens drei andere CoW-Dateisysteme, die all das können oder sollen, soweit ich weiß: nilfs2, bcachefs und xfs.)
Obwohl Sie das nicht erwähnt haben, ist meines Wissens keine Deduplizierungstechnologie dateitypbewusst. Mit anderen Worten, kein Deduplizierer weiß, dass er *.jpg-Metadaten überspringen und nur die komprimierten Bilddaten für die Deduplizierung berücksichtigen soll. Ebenso berücksichtigt keiner von ihnen magische Dateizahlen (zumindest nicht, um zu bestimmen, was für die Deduplizierung berücksichtigt werden soll). Das könnte ein Killer-Feature sein – erfordert allerdings sicherlich ständige, fortlaufende Definitionsaktualisierungen. Und es könnte wirklich schwer zu entwerfen sein, während Dateien gleichzeitig als abstrakte M:M-Sammlung von Extents, Blöcken usw. behandelt werden.