Avoiding fragmentation

The secret is to not write uncompressed files on the disk to begin with.

Indeed, after you compress an already existing large file it will become horrendously fragmented due to the nature of the NTFS in-place compression algorithm.

Instead, you can avoid this drawback altogether by making OS compress a file's content on-the-fly, before writing it to the disk. This way compressed files will be written to the disk as any normal files - without unintentional gaps. For this purpose you need to create a compressed folder. (The same way you mark files to be compressed, you can mark folders to be compressed.) Afterwards, all files written to that folder will be compressed on the fly (i.e. written as streams of compressed blocks). Files compressed this way can still end up being somewhat fragmented, but it will be a far cry from the mess that in-place NTFS compression creates.

Example

NTFS compressed 232Mb system image to 125Mb:

• In-place compression created whopping 2680 fragments!
• On-the-fly compression created 19 fragments.

Defragmentation

It's true that NTFS compressed files can pose a problem to some defragment tools. For example, a tool I normally use can't efficiently handle them - it slows down to a crawl. Fret not, the old trusty Contig from Sysinternals does the job of defragmenting NTFS compressed files quickly and effortlessly!

How are you measuring the compression savings? Something is wrong in your numbers, because an RTM 8.1 image will save about 114 MB from the NTFS compression of in-box drivers alone (on x64). Just use explorer to get the size of c:\windows\system32\driverstore, and you will see there is about 114 MB difference between the "Size" and the "Size on disk". /startcomponentcleanup does not re-do work it has already done, so running it in the future will only have to compress new drivers, backup files, or superseded files.

With an RTM 8.1 image there is very little in the backups category that needs to be compressed, and there shouldn't be anything in the superseded category. The superseded category is the only compression that is skipped when /startcomponentcleanup /resetbase is used instead of normal /startcomponentcleanup. So, I'm not sure what advantage you are seeing by using it as far as compression performance. Compression of superseded bits (when you have them) does take some time, but it maintains your ability to uninstall a KB, while saving >90% of the space.

To see the accurate numbers for the effects of /startcomponentcleanup or /startcomponentcleanup /resetbase on winsxs, run dism /online /cleanup-image /analyzecomponentstore before and after running /startcomponentcleanup... Look specifically at the "Backups and disabled features" numbers. You will notice that there is a significant difference after running the command. Also, if you re-run /startcomponentcleanup, you should see that it completes fairly quickly the 2nd time, because there isn't anything for it to do.

Edit - Some actual numbers for comparison

For example on an X64 computer I just updated with January patch Tuesday updates (including optional updates), here's how compression breaks out, looking at just changes due to Jan. patch.

Note: The savings below come from compression that is not NTFS' compression and therefore the compressed files do not show as compressed in file explorer. NTFS compression is only used by /startcomponentcleanup for inbox driver compression (which is not included below and amounts to about 114 MB of savings for the driverstore)

Actual numbers using /startcomponentcleanup

+354.25 MB added for January updates
- 34.14 MB saved by superseded package removal
- 67.84 MB saved for Backups (99.86 MB compressed to 32.02 MB) 
-203.36 MB saved for Superseded Components (220.25 MB compressed to 16.89 MB) 
 ---------
  48.91 MB growth due to January updates after /startcomponentcleanup

Actual numbers using /startcomponentcleanup /resetbase

If you use "/startcomponentcleanup /resetbase" instead of just "/startcomponentcleanup", you save an additional 16.89 MB, but now you can't uninstall any remaining updates, and you may note that all of the same compressions are performed as above, except for "Superseded Components."

  48.91 MB growth due to January updates after /startcomponentcleanup
- 16.89 MB savings due to /resetbase
 ---------
 32.02 MB growth due to January updates after /resetbase

Example of using /analyzecomponentstore

Here's the results of running /analyzecomponentstore after applying January updates, and after running /startcomponentcleanup. Pay attention to the "Backups and Disabled Features" number, because that indicates the non-temporary storage needed for the component store (winsxs).

After applying January updates

Windows Explorer Reported Size of Component Store : 5.75 GB

Actual Size of Component Store : 5.51 GB

    Shared with Windows : 4.49 GB
    **Backups and Disabled Features : 884.98 MB**
    Cache and Temporary Data : 161.29 MB

Date of Last Cleanup : 2014-01-14 10:04:32

Number of Reclaimable Packages : 3
Component Store Cleanup Recommended : Yes

After running /startcomponentcleanup

Windows Explorer Reported Size of Component Store : 5.33 GB

Actual Size of Component Store : 5.21 GB

    Shared with Windows : 4.49 GB
    **Backups and Disabled Features : 595.02 MB**
    Cache and Temporary Data : 139.23 MB

Date of Last Cleanup : 2014-01-14 10:38:59

Number of Reclaimable Packages : 0
Component Store Cleanup Recommended : No