ZFS compresja i deduplikacja na przykładzie danych z systemu NEXUS (Zettabyte File System)

Go to start of metadata
Wersja zfs:
cat /sys/module/zfs/version
0.7.5-1

Niestety, w tym konkretnym systemie NEXUS'a trzymane są pliki ".jar", a nie tylko kody i dane konfiguracyjne. Implikuje to dwa zaobserwowane efekty:
1) Duże, i przecież już skompresowane, pliki są przechowywane na dysku, zamiast samych kodów i mechanizmów budujących je. Nie można efektywnie skompresować pliku poddanego już kompresji, więc mechanizm kompresujący na poziomie systemu plików (sektorów) okazał się nieefektywny.
2) Nawet minimalna zmiana kodów powoduje, że zbudowane archiwum ma inne położenie bajtów (sektory są różne, chociaż zmiany w kodzie mogą dotyczyć jednej linii),czyli nie da się efektywnie przeprowadzić deduplikacji. 
Poniżej screeny ze statystykami. Kompresja na poziomie 1,16 - co nie jest najgorszym wynikiem. Deduplikacja na poziomie 1,23 - co jest już nie do przyjęcia, ze względu na relację: koszt obliczeniowy i zajętość pamięci RAM do zysku w postaci zwiększenia miejsca na dysku. W tym konkretnym przypadku, za względu na wadliwe użycie menadżera repozytoriów, zastosowanie mechanizmów systemu ZFS nie przynosi oczekiwanego zysku.


 ********

Więcej informacji:
Informatyka, FreeBSD, Debian


***

Inne wpisy:



Update: 2018.07.17
Create: 2018.07.17

Brak komentarzy:

Prześlij komentarz