ZFS Deduplizierung

Um ein Gefühl für die, mit der v28 verfügbar gewordene Deduplizierungsfähigkeit von ZFS zu bekommen habe ich auf einem FreeBSD 9.0 System eine zusätzliche Platte angehängt und diese mit ZFS versehen.
Als Testdaten kommt ein Verzeichnis mit "Real-World"- Daten mit einer unkomprimierten und nicht deduplizierten Datenmenge von 1,9 GB zum Einsatz. Die Daten sind stark gemischt und beinhalten Plaintext- Dateien, Office- Dokumente, PDFs, Grafiken usw. Erstmal ein Vergleich zwischen den Daten auf einem UFS (/home/rs/SA) und einem ZFS (/tank0/pfad0) Volume:  

[root@fb90 /tank0/pfad0]# du -ksh /home/roland/SA/; du -ksh /tank0/pfad0/SA/
1.9G    /home/rs/SA/
1.2G    /tank0/pfad0/SA/

  In der "ZFS-Ansicht" ist nun auch zu erkennen, dass 1,24 GB Platz eingenommen wird.

 

[root@fb90 /tank0/pfad0]# zfs list tank0/pfad0
NAME          USED  AVAIL  REFER  MOUNTPOINT
tank0/pfad0  1.24G  2.69G  1.24G  /tank0/pfad0

  Von diesen Rohdaten kann das System durch Deduplizierung bereits ~34 MB Daten einsparen.  

[root@fb90 /tank0/pfad0]# zdb -b tank0

Traversing all blocks to verify nothing leaked ...

        No leaks (block sum matches space maps exactly)

        bp count:           21432
        bp logical:    2035784192      avg:  94988
        bp physical:   1330266112      avg:  62069     compression:   1.53
        bp allocated:  1337577472      avg:  62410     compression:   1.52
        bp deduped:      34008064    ref>1:   1225   deduplication:   1.03
        SPA allocated: 1303569408     used: 30.59%

  Im nächsten Schritt dupliziere ich das Verzeichnis einfach:  

[root@fb90 /tank0/pfad0]# cp -R SA/ SA2

  Nachdem die Daten nun doppelt sind greift die Deduplizierung nun auch wesentlich besser- wen wundert das ;-)

 

[root@fb90 /tank0/pfad0]# zdb -b tank0

Traversing all blocks to verify nothing leaked ...

        No leaks (block sum matches space maps exactly)

        bp count:           42126
        bp logical:    4067435520      avg:  96554
        bp physical:   2658508288      avg:  63108     compression:   1.53
        bp allocated:  2669537280      avg:  63370     compression:   1.52
        bp deduped:    1358875136    ref>1:  15826   deduplication:   1.51
        SPA allocated: 1310662144     used: 30.76%

  Auf der Betriebssystemebene sieht das nun mittlerweile richtig interessant aus- tank0 ist eigentlich eine 4 GB grosses Volume das mittlerweile eine Kapazität von 5,1 GB hat:
    

[root@fb90 /tank0/pfad0]# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/da0p2      14G    3.9G    9.7G    28%    /
devfs          1.0k    1.0k      0B   100%    /dev
tank0          2.7G     32k    2.7G     0%    /tank0
tank0/pfad0    5.1G    2.5G    2.7G    48%    /tank0/pfad0

  Auch ZFS ist der Ansicht, dass das Volume inzwischen wesentlich größer ist als es eigentlich ist:

 

[root@fb90 /tank0/pfad0]# zfs list tank0/pfad0
NAME          USED  AVAIL  REFER  MOUNTPOINT
tank0/pfad0  2.48G  2.67G  2.48G  /tank0/pfad0

  Wichtig ist im Endeffekt ja auch nur die Angabe wieviel Platz noch verfügbar ist damit man rechtzeitig über eine Vergrößerung des Volumes nachdenken kann. Kopiert man nun die Daten nochmals kann man dieses Verhalten auch weiterhin beobachten:  

[root@fb90 /tank0/pfad0]# cp -R SA/ SA3

     

[root@fb90 /tank0/pfad0]# zdb -b tank0

   

Traversing all blocks to verify nothing leaked ...
        No leaks (block sum matches space maps exactly)

        bp count:           62535
        bp logical:    6097919488      avg:  97512
        bp physical:   3986446848      avg:  63747     compression:   1.53
        bp allocated:  4000546816      avg:  63972     compression:   1.52
        bp deduped:    2683742208    ref>1:  15826   deduplication:   1.67
        SPA allocated: 1316804608     used: 30.90%

   

[root@fb90 /tank0/pfad0]# zfs list tank0/pfad0
NAME          USED  AVAIL  REFER  MOUNTPOINT
tank0/pfad0  3.72G  2.64G  3.72G  /tank0/pfad0

  Und auch im Betriebssystem selbst ein analoges Bild:

 

[root@fb90 /tank0/pfad0]# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/da0p2      14G    3.9G    9.7G    28%    /
devfs          1.0k    1.0k      0B   100%    /dev
tank0          2.7G     32k    2.7G     0%    /tank0
tank0/pfad0    6.4G    3.7G    2.7G    58%    /tank0/pfad0

  Um es ganz deutlich zu machen werden die Daten nochmal dupliziert- somit haben wir ein 4 GB Volume, das Platz für 7,6 GB Daten hat ;-)  

[root@fb90 /tank0/pfad0]# cp -R SA/ SA4

   

[root@fb90 /tank0/pfad0]# zdb -b tank0
Traversing all blocks to verify nothing leaked ...
        No leaks (block sum matches space maps exactly)

        bp count:           82947
        bp logical:    8128428032      avg:  97995
        bp physical:   5314377216      avg:  64069     compression:   1.53
        bp allocated:  5331527168      avg:  64276     compression:   1.52
        bp deduped:    4008609280    ref>1:  15826   deduplication:   1.75
        SPA allocated: 1322917888     used: 31.04%

[root@fb90 /tank0/pfad0]# zfs list tank0/pfad0
NAME          USED  AVAIL  REFER  MOUNTPOINT
tank0/pfad0  4.96G  2.62G  4.96G  /tank0/pfad0

   

[root@fb90 /tank0/pfad0]# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
/dev/da0p2      14G    3.9G    9.7G    28%    /
devfs          1.0k    1.0k      0B   100%    /dev
tank0          2.6G     32k    2.6G     0%    /tank0
tank0/pfad0    7.6G      5G    2.6G    65%    /tank0/pfad0

  Zusammenfassend lässt sich sagen, dass man mit der Deduplizierung als Admin nun ein sehr mächtiges Werkzeug an der Hand hat um die Daten- Sammelwut der Benutzer sauber in den Griff zu bekommen. Und das sogar dann wenn man nicht unbedingt eine Celerra von EMC oder ähnliche Geräte, die eine eingebaute Deduplizierung haben, im Einsatz hat.
Selbstverständlich werden die Faktoren im obigen Beispiel nur selten erreicht werden- schliesslich habe ich ein und das gleiche Verzeichnis einfach mehrfach abgelegt- ein gefundenes Fressen für den Algorithmus. Nutzt man ein ZFS Volume als Ziel für Datensicherungen ist es aber durchaus möglich auf ähnliche Werte zu kommen.