kopieren / verschieben von Daten von / auf zpools mit eingeschaltetem dedup

[ron2105]

Hallo Zusammen,

ich kopiere gerade erfolgreich (wie im letzten Thread berichtet) meine Daten von einem zpool ohne dedup auf einen temporären zpool mit eingeschaltetem dedup (derzeit dedupratio=2,41 und steigend). Nach Ende des Kopiervorganges soll der ursprüngliche zpool zerstört werden und mit zusätzlichen Disks als raidz2 mit eingeschaltetem dedup wieder in Betrieb gehen. Die jetzt zwischengelagerten Daten sollen danach wieder auf das raidz2. Ich wäre sehr froh darüber, wenn der Rückkopiervorgang nicht über den Weg der "Datenwiederherstellung" also 1. De-Deduplikation -> 2. Dekomprimierung -> 3. Originaldaten im RAM -> 4. Komprimierung -> 5. erneute Dedup-Berechnung , sondern eventuell durch kopieren der deduplizierten und komprimierten Daten direkt auf den zpool. Wird diese Rechenorgie eventuell durch den Befehl zfs send umgangen? Funktioniert dies überhaupt auf ein und dem selben Host (von einem zpool zum anderen)? Ist ein einfaches dd der richtige Weg?
Fragen über Fragen.... und hoffentlich ein schlauer Mensch, sie mir zu beantworten.
Vielen Dank im Voraus.
Gruß
Ron

[erisch]

Imho wird zfs send wird die Daten neu deduplizieren. Wenn man naemlich einen un-dedupliziertes dataset in einen pool mit dedup sendet, werden die Daten auch dedupliziert.

Von dd wuerde ich im Umgang mit ZFS generell die Finger lassen.

Senden und empfangen von snapshots auf dem selben System geht natuerlich, wieso auch nicht?

Wieso machst du dir um de Rechenarbeit ueberhaupt so ne Platte. Ne moderne Kiste sollte das locker abkoennen. Du kannst ja waehrend des Sendens mal ein iostat -xnz laufen lassen und die Plattenauslastung auslesen. Da wirste schnell feststellen obs an der CPU oder den Platten haengt.

Ich kann aber morgen mal die Experten fragen, obs nen Weg gibt die Daten ohne Umwandlung von a nach b zu schieben.

Mfg. Erisch

[erisch]

Also: zfs send erhaelt dir die komprimierten Daten. Das heisst, es wird nicht dekomprimiert, gesendet und dann wieder komprimiert.

Bei dedup ist das anders. Das Problem ist, dass Kompression auf dataset-Ebene stattfindet, d.h. du schiebst einfach das ganze dataset in den anderen pool, egal ob die daten da drin komprimiert sind oder nicht. Dedup allerdings arbeitet auf pool-Ebene und wenn du einen zfs send stream empfaengst, koennten ja die Bloecke im stream schon irgendwoanders im pool vorraetig sein. Deswegen wirst du da um etwas Rechenarbeit nicht herumkommen (oder besser dein Computer).

Aber: Es gibt einen ARC case in dem der send stream selbst dedupliziert wird:
http://arc.opensolaris.org/caselog/PSARC/2009/557/20091013_lori.alt. Dann eruebrigt sich auch die Deduplizierung auf Empfaengerseite weil nur die checksums verglichen werden muessen. Fuers senden brauchst du allerdings CPU power. Das hat aber dann den Vorteil, dass der send stream kleiner wird.

Soweit ich das sehe ist dieses -D flag fuer zfs send noch nicht "put back" und im Moment ist ON sowieso restricted fuer neue Funktionen deswegen wird das noch paar builds dauern bis das benutzbar ist.

Mfg. Erisch

[ron2105]

Hallo,

vielen Dank erst einmal für die ausführliche Antwort.
Wenn ich mit dem ersten Kopiervorgang (auf den temporären Spiegel) fertig bin, was bei 1,1MB/s wohl noch etwas länger dauern wird, werde ich mal versuchen, die Daten per zfs send wieder zurückzuschaufeln.
Generell kann ich mir nicht vorstellen, dass eine so miese Geschwindigkeit nur durch die Plattenauslastung zustande kommt, obwohl der Lesepool (raidz2 mit 5x 1TB SATA2) und der Schreibpool (mirror z.Zt. mit 2x 250GB SATA2) an einem Controller hängen. Eine iostat-Abfrage ergibt allerdings, dass die CPU nur zu 40% ausgelastet ist.

Gruß
Ron

[ron2105]

Hallo,

ich habe da noch einmal eine Frage.
Ich bin immer noch dabei, die Daten (Backups virtueller Maschinen) auf den temporären mirror-zpool zu kopieren, musste ihn aber aus Platzmangel um 2 HDDs 500GB (leider nur IDE) erweitern. Bis zur Erweiterung erhöhte sich die Deduprate kontinuierlich bis 2,9 , nach der Erweiterung fällt sie wieder, obwohl die Daten eigentlich weitestgehend auch wieder nur Kopien der anfänglichen Daten sind. Ich habe den Eindruck, dass dedup nur innerhalb eines Mirrors funktioniert, aber die Deduprate für den gesamten zpool angegeben wird. Tante Google hatte leider keine Angaben zu diesem Thema.

Gruß
Ron