Do testu użyłem danych z systemu http://nexus.amg.net.pl/index.html#welcome - http://www.sonatype.org/nexus/
Wersja zfs:
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.
********
***
Inne wpisy:
Oświetlenie miejsca pracy
Oświetlenie LED łazienki (małej)
Zużycie prądu przez suszarkę do ubrań i pralkę
Zużycie prądu przez urządzenia domowe i ich współczynnik mocy cos phi (cosφ)
Modernizacja oświetlenia głównego w dużym pokoju i przedpokoju
Oświetlenie LED łazienki (małej)
Zużycie prądu przez suszarkę do ubrań i pralkę
Zużycie prądu przez urządzenia domowe i ich współczynnik mocy cos phi (cosφ)
Modernizacja oświetlenia głównego w dużym pokoju i przedpokoju
Update: 2018.07.17
Create: 2018.07.17