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.