Macrium doesn't seem to find the process at all difficult. It just
clones the source to the destination without complaint or extra time.
I've done it dozens of times.
OK, I tried an experiment. Because of what I could see
in the Application Data folder.
When I ran a backup with Macrium, a file with extension .vsslog
was left. And in there, are some log entries for what it was doing.
I figured, I'd test your situation (clone larger disk to smaller
disk), and then examine the .vsslog after it was finished. This
would be "clone", rather than backup.
To my surprise, the .vsslog file did not get updated. So "clone"
doesn't leave the same evidence trail as "backup" does.
I cloned a 250GB drive to a 160GB drive. And the single partition I
tested with, had maybe 147GB of files, in various states of fragmentation.
The destination disk, ended up pretty full (as expected), and with
less fragmentation. Not zero fragmentation, due to the fullness of
the disk, and the need to convert $MFT reserved space into file
storage space. The transfer couldn't have all fragmentation removed.
In terms of the transfer characteristic, it "looked like a VSS transfer"
in that the disk heads didn't seem to be flying all over the place. The
transfer seemed to be roughly sequence, at around 45MB/sec (old disks).
The transfer rate was steady - not like the Robocopy transfers I do
all the time here, which can vary from as low as 1MB/sec to 135MB/sec
(depending on file sizes). Using Performance Monitor, tells me the
transfer is likely VSS based.
But with no .vsslog to go on, there are no log comments to analyse.
And determine how this mode of transfer is possible.
Since it doesn't create a log, that almost suggests the function in
question (clone n' squeeze), is built into something. But without
any log file, "their secret is safe".
A file "XMLFiles.dat" had the date changed on it, but the file
is virtually empty. I don't know if that had something to do
with it, or not. I tried Googling that, and didn't get anywhere.
My conclusion is, the VSS stuff has something magical to
do for file-by-file operations. And that means the
Wikipedia article that claims it is block oriented,
might not strictly be true.
You know, this evidence just doesn't make sense. If the
files are repositioned, then they're written to different
offsets in the new partition. You can't have a "smooth" transfer
curve if that is the case. The only way the transfer curve could
be smooth, is if the reader and writer are both sequential. But
to rewrite the files, as has been done here, some of the files
must be out of order, and the head movement for that, should
cause the Performance Monitor transfer rate graph to be "spiky".
So it really is magical...
I checked with NFI (the NTFS file listing utility), and
it appears the "clone n' squeeze" processes files in file number
order. But the files on the source disk, wouldn't be in spatial
order (for a disk that is well fragmented). The destination is
pretty well ordered (written in spatial order), and not too fragmented.
The last four large files transferred, didn't have any fragments at all.
Even though that partition is very close to full.
"Processed in file order, written in spatial order
(File 41 on the source disk, is also kav_rescue_10__Feb24_2013.iso)"
logical sectors 10150984-10729079 (0x9ae448-0xa3b677)
logical sectors 10729080-10729839 (0xa3b678-0xa3b96f)
logical sectors 10729840-12157799 (0xa3b970-0xb98367)
So maybe VSS does it that way all the time, and I just missed
it ? There just doesn't seem to be that much head movement when
VSS copying is going on. Guess I'll need a "severely fragmented"
disk to shine more light on how it works.