Як я підозрював, вона базується в підсистемі VSS ( джерело ), що також пояснює її асинхронну природу. Шматки де-дуп зберігаються в \System Volume Information\Dedup\ChunkStore\*
, з налаштуваннями в \System Volume Information\Dedup\Settings\*
. Це має значний вплив на те, як ваше програмне забезпечення для резервного копіювання взаємодіє з такими обсягами, що пояснено у прив’язаній статті (коротко: без підтримки дедупи ваші резервні копії будуть такого ж розміру, як вони є завжди, при підтримці дедупи ви просто резервуєте. значно менший магазин дедуп).
Щодо застосованих методів, найкраще, що я міг знайти, - це дослідницький документ, викладений дослідником Microsoft у 2011 році ( джерело , повний текст ) на конференції Usenix FAST11. Розділ 3.3 переходить до дедупликації в первинному зберіганні . Здається, ці дані були використані при розробці функції дедукції NTFS. Ця цитата була використана:
Канонічний алгоритм для блоків, визначених змістовим розміром, є відбитками пальців Рабіна [25].
У статті є багато даних, які потрібно просіяти, але складність використовуваного набору інструментів у поєднанні з функціями, які ми знаємо вже у 2012 році, настійно свідчать про те, що міркування в роботі використовувались для розробки особливостей. Напевно не можу знати без статей msdn, але це так близько, наскільки ми, швидше за все, отримаємо.
Порівняння продуктивності з ZFS доведеться почекати, поки контрольні показники не зроблять це.