Как я и подозревал, он основан на подсистеме VSS ( источник ), что также объясняет его асинхронную природу. Куски де-дупе хранятся в \System Volume Information\Dedup\ChunkStore\*, с настройками в \System Volume Information\Dedup\Settings\*. Это оказывает существенное влияние на то, как ваше программное обеспечение для резервного копирования взаимодействует с такими томами, что объясняется в связанной статье (вкратце: без поддержки дедупликации резервные копии будут иметь тот же размер, что и всегда, а с поддержкой дедупликации вы просто создадите резервную копию. гораздо меньший дедуплицирующий магазин).
Что касается использованных методов, лучшее, что я смог найти, - это исследовательская работа, выпущенная исследователем Microsoft в 2011 году ( источник , полный текст ) на конференции Usenix FAST11. Раздел 3.3 посвящен дедупликации в основном хранилище . Вероятно, эти данные использовались при разработке функции дедупликации NTFS. Эта цитата была использована:
Каноническим алгоритмом для блоков контента с переменным размером является Rabin Fingerprints [25].
В документе есть много данных, которые необходимо проанализировать, но сложность набора инструментов, который они использовали, в сочетании с функциями, которые мы знаем уже в 2012 году, настоятельно свидетельствуют о том, что рассуждения в документе использовались для разработки функций. Не могу знать наверняка без статей msdn, но это так близко, как мы, вероятно, пока получим.
Сравнение производительности с ZFS придется подождать, пока тестеры не покончат с этим.