s|b said:
I did find an example of a tool, that doesn't support
shrinking on a clone. And the picture that accompanies
this page, shows them just copying the busy sectors.
http://www.runtime.org/driveimage-xml.htm
A little more testing on Macrium, shows they have written
something to do the shrinking, and the characteristics
are quite different. The mystery, is how they do it
(without screwing it up). This isn't an operation
you find every day on a computer.
The Macrium tool, does (256) 4K reads, then blasts out
a 1MB write in one shot. Which doesn't match the driveimage-xml
picture at all. Maybe the reason it looks like that, is my
sample clone had an almost-full partition, so very few
blocks were empty.
What it implies, is the potential of doing ordinary file
copies, with only one file table update (which would
be faster and quieter, if it was a common option).
It doesn't seem to be Microsoft software doing the shrink,
as by using vsstrace, the VSS subsystem is quiet while
Macrium is doing the copy n' shrink. The shadow copy is
released at the end, like you'd expect.
So how do they figure out where to put stuff ? The
pattern I see, it almost looks like they compute what
the $MFT should look like, rather than build it by
doing file copies and having a file system do it.
Many other things we see done to file systems, are
done "bit-by-bit". When your disk is defragmented,
it's done one file at a time, and the $MFT updated
after each one. If you copy files, it is done one
at a time. Software almost never "globs together"
operations in one shot. The shadow copy is certainly
safe to play with, so the developers aren't taking
a risk with user data on the source end. Like, if
the power goes off. They can always freeze another
shadow copy and try again. So the opportunity is
certainly present.
I was expecting most of these one-off backup companies
(that produce a "free utility" based on VSS), they
were doing it because it was easy to write. The
Macrium software seems to have value-added.
Paul
and it