taka ciekawostka a propos eMeSeowego DD…
- eMeSowy DD działa na poziomie plików – nad sterownikiem NTFS a nie pod nim [..może raczej 'obok’.. albo 'wraz z’… hmmm. ciężko umiejscowić 'filter drivers’ w geometrii przestrzennej (; ]. to zupełnie zmienia logikę działania
- efekty DD oraz scenariusze zastosowania będą zupełnie inne dla DD macierzowego a tego eMeSowego. dobrym przykładem będzie DD dla backupów SQL – bez względu czy użyje się kompresji czy nie, zysk z DD będzie oscylował w okolicach 7o-8o%. tutaj można poczytać o ciekawych testach z tym związanych. w jednym ze środowisk uzyskałem ratio 92% dla backupów SQL (muszę dodać, że przy małej ilości zmian na bazie, więc test nie jest zbyt miarodajny, ale i tak robi wrażenie).
- podczas projektowania przestrzeni dyskowej trzeba pamiętać, że operacja nie jest robiona w locie tylko w cyklach -czyli projekt musi zawierać 1oo% przestrzeni dla danych które będą się pojawiać. co więcej – deduplikacji (standardowo) nie podlegają pliki młodsze niż 3 dni,warto ustawić 'minimumFileAge’ na 0 żeby operacja została wykonana od razu jeśli to nie jest wolumen z aktywnie używanymi danymi. jest również wiele typów pliqw, które nie są ruszane, ze względu na to, że z góry wiadomo, że będzie to efektywne – głównie chodzi o już skompresowane pliki. z tego powodu bardzo jestem zdziwiony wynikami z backupem SQL.
eN.
