Working Deduplication files for Microsoft Windows 10

You need to login to view this posts content.

 

Will we get an update for Build 14901 ?

 

Of course not, why one would need it on preview build?

 

I was not sure if we need it, because when I updated Win10 from Build 14393.10 to 14393.67 via Homebrew-ISO, I had to re-install the Dedup-Pack, because I was unable to access my files.

Now, after I updated to 14901, I have again Access-Issues, but can't re-apply the old package.

 

14901 is a different os, will not accept or install 14393 package normally

going from 14393.10 to 14393.67 require cumulative update, doesn't affect dedup pack
unless you did in-place upgrade

 

Will do a clean install via 14393.67-ISO and re-install dedup and might just undo it.

 

You need to login to view this posts content.

 

Should it work for dedup of boot volume?

en_windows_10_enterprise_2016_ltsb_n_x64_dvd_9057894.iso, dedup package from first post installed fine

Code:

PS C:\Windows\system32> Enable-DedupVolume -Volume c:
Enable-DedupVolume : MSFT_DedupVolume.Volume='c:' - HRESULT 0x8056530b, The specified volume type is not supported.
Deduplication is supported on fixed, write-enabled NTFS data volumes and CSV backed by NTFS data volumes.
At line:1 char:1
+ Enable-DedupVolume -Volume c:
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (MSFT_DedupVolume:ROOT/Microsoft/...SFT_DedupVolume) [Enable-DedupVolume],
    CimException
    + FullyQualifiedErrorId : HRESULT 0x8056530b,Enable-DedupVolume

 

Nope.

 

That is king of "silly"... and the error even more! (but then most of MS errors are odd)

 

It's understandable, the deduplication is an intensive process and the system volume has a zillion of files changing continously.

Also the typical scenario is one small disk/partition for the os and a large one for the data.

Last but not least an error on deduplicated data can be easily fixed by the scheduled task w/o much hassle, while the os needs all of its files accessible in real time.

Anyway an experiment i wish to test is to deduplicate the system volume using another os, then add the dedup filter to the boot services of the os residing on the deduped volume.

I bet it will boot.

 

Please let know of the result, really interesting

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

You need to login to view this posts content.

 

Interesting...I wonder how that would work to load a driver from a volume that is deduped? If the driver is not loaded yet how could the "boot process/mbr/bootmgr/bcd" even access the deduped driver which is on a deduped volume to load it? Still interested to see if this works, please let us know.

~MC

 

You can exclude files, dirs and extensions from the dedupe process. Even a fully compressed FS is bootable. It needs just a couple of files excluded from the compression process

So, I guess that tecnhically, excluding the few files used by the initial boot process should be enough to make the system working.

Anyway practically the boot could be blocked purposely by some hardcoded checks that could block the boot process, no matter the above precautions.

Only a real world test can tell, and I'm busy with other things right now.

But feel free to experiment with my idea

 

rollup = group of updates, instead installing them separately

it's for both

by extracting the package .cab file, and looking into .mum files

6.4 is windows 10 before the bump