Seperti yang saya duga, itu berbasis di subsistem VSS ( sumber ) yang juga menjelaskan sifatnya async. Potongan de-dupe disimpan dalam \System Volume Information\Dedup\ChunkStore\*
, dengan pengaturan di \System Volume Information\Dedup\Settings\*
. Ini memiliki dampak signifikan terhadap bagaimana perangkat lunak cadangan Anda berinteraksi dengan volume seperti itu, yang dijelaskan dalam artikel yang ditautkan (secara singkat: tanpa dukungan dukungan, cadangan Anda akan memiliki ukuran yang sama seperti biasanya, dengan dukungan gabungan, Anda hanya akan membuat cadangan toko dedupe yang jauh lebih kecil).
Adapun metode yang digunakan, yang terbaik yang bisa saya temukan adalah makalah penelitian yang dikeluarkan oleh seorang peneliti Microsoft pada tahun 2011 ( sumber , fulltext ) di konferensi Usenix FAST11. Bagian 3.3 membahas Deduplikasi di Penyimpanan Utama . Sepertinya data ini digunakan dalam pengembangan fitur dedupe NTFS. Kutipan ini digunakan:
Algoritma kanonik untuk blok konten-ukuran yang ditentukan variabel-variabel adalah Rabin Fingerprints [25].
Ada banyak data dalam makalah yang perlu disaring, tetapi kompleksitas toolset yang mereka gunakan, dikombinasikan dengan fitur yang kita tahu pada tahun 2012, sangat menyarankan bahwa alasan dalam makalah ini digunakan untuk mengembangkan fitur. Tidak dapat mengetahui pasti tanpa artikel msdn, tapi ini sedekat yang mungkin kita dapatkan untuk saat ini.
Perbandingan kinerja dengan ZFS harus menunggu sampai benchmarker selesai dengannya.