Thanks for your response Eric but I disagree with your assessment and here is why:<br><br>Functionally - I agree that Windows is bound to update multiple timestamps on log files, registry entries, pagefile, etc every time it boots.  However I think it is unrealistic to assume literally half of the capacity used on a WinXP install is due to logs.  To put it a different way, the system was only booted up for about 3 minutes (long enough to log in, download winscp and shut it down).  Assuming my VM wrote 7 gigs of data non-stop for that 3 minute period that's a maximum of 7000000000 bytes / 180s =~ 38.9 MB/s.  That is a _serious_ performance hit and would be very apparent in performance monitoring tools... and there was no such hit.<br>

<br>Alternate assessment - I ran a similar comparison against the two image files using rdiff that comes with Ubuntu 10.04.4 LTS (shown up as librsync 0.9.7) and have a significantly smaller delta file (closer to what i expect).<br>

<ol><li>Commands:</li><ol><li>rdiff signature image1 image1-signature</li><li>rdiff delta image1-signature image2 image1to2-delta</li></ol><li>Resultant files:</li><ol><li>image1-signature - 99,975,264 bytes</li><li>image1to2 delta - 446,384,815 bytes</li>

</ol></ol><br>So the two commands (rsync and rdiff) use the same or very similar underlying libraries and result in a 426 MB delta file vs 6.9 GB delta file!  To me, that is a clear indication that either I am running the rsync command incorrectly, or that there is a bug in rsync.  Does that make sense?<br>

<br>Matt<br><br><div class="gmail_quote">On Tue, Mar 20, 2012 at 2:07 PM,  <span dir="ltr"><<a href="mailto:ericbambach1@discover.com">ericbambach1@discover.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Matt,<br>
<br>
        Its probably not a rsync bug. Its likely that after booting to<br>
create the second image a large number of updates has happened at many<br>
different parts in the filesystem. You may have added only a few MB of<br>
data but a lot of little things are going on in an active system like<br>
filesystem timestamp updates, registry updates, etc. It could also have to<br>
do with the internal structure of the image. If it stores metadata about<br>
each part of the system the metadata could be different between runs<br>
causing a large number of differences.<br>
<br>
        A 7GB diff of a 16GB file tells me about half the blocks were<br>
modified between runs which isn't completely unbelievable in an active,<br>
booted system.<br>
<br>
Eric Bambach | Discover<br>
Senior Assoc. Programmer, Warehouse Infrastructure and Tools<br>
2500 Lake Cook Road, Riverwoods IL 60015<br>
P: <a href="tel:224.405.2896" value="+12244052896">224.405.2896</a> <a href="mailto:ericbambach1@discover.com">ericbambach1@discover.com</a><br>
<br>
<br>
<br>
<br>
From:   Matt Van Mater <<a href="mailto:matt.vanmater@gmail.com">matt.vanmater@gmail.com</a>><br>
To:     <<a href="mailto:rsync@lists.samba.org">rsync@lists.samba.org</a>><br>
Date:   03/20/2012 12:55 PM<br>
Subject:        Batch mode creates huge diffs, bug(s)?<br>
Sent by:        <<a href="mailto:rsync-bounces@lists.samba.org">rsync-bounces@lists.samba.org</a>><br>
<div class="im"><br>
<br>
<br>
So the short summary of my problem is, the batch file rsync creates is<br>
HUGE for a very small change.  The idea is to create workstation image<br>
with partimage, update it with some software and send the image update<br>
diff over the wire to a large number of destinations over a satellite<br>
link, but the batch file updates are several orders of magnitude too<br>
large.  I don't know exactly how partimage creates image files, so the<br>
bytes/blocks may be ordered differently between my two variants but should<br>
be identical, so rsync _should_ be able to handle that right?<br>
<br>
Software used: Ubuntu 9.10, <a href="http://fogproject.org" target="_blank">fogproject.org</a> v.28, partimage ??, rsync 3.0.6<br>
Hardware: Running as VM in ESXi 4.1 U2, 4 x vCPU and 16 GB RAM, 200 GB<br>
disk (150+ GB free)<br>
<br>
My testing process:<br>
</div>1.      Use FOG .28 / partimage to capture an image of and already<br>
configured Windows XP workstation<br>
2.      Log in to workstation as normal user, download WinSCP (2.9 MB<br>
<div class="im">file), shut down machine gracefully<br>
</div>3.      Use FOG .28/partimage /  to capture the same system again, to a<br>
new image file.<br>
4.      FOG uses gzip to compress the partimage file, and we need to<br>
compare uncompressed images<br>
1.      Commands:<br>
1.      mv image1 image1.gz && mv image2 image2.gz && gunzip image1.gz &&<br>
gunzip image2.gz<br>
2.      Resultant files:<br>
1.      image1 size in bytes: 17,062,442,700<br>
2.      image2 size in bytes: 16,993,256,652<br>
3.      Difference in raw size in bytes: 69,186,048 (somewhat larger than<br>
<div class="im">the 2.9 MB difference I expect due to downloading WinSCP, but not the end<br>
of the world)<br>
</div>5.      Create rsync diff package<br>
1.      Command:<br>
1.      rsync –only-write-batch=img1toimg2_diff image2 image1<br>
2.      Resultant files:<br>
1.      img1toimg2_diff size in bytes: 7,315,408,780<br>
2.      img1toimg2_diff.sh in bytes: 58<br>
3.      Difference is WAY bigger than raw file size. This HAS to be a bug!<br>
<div class="im">I thought perhaps specifying the block size might help (it does<br>
significantly in non-batch mode) but I get a error and cannot proceed.  I<br>
have tried in both rsync v3.0.6 and v3.0.7 to specify the block size, but<br>
the result is the same:<br>
</div>1.      Command:<br>
1.      rsync --block-size=512 –only-write-batch=img1toimg2_diff image2<br>
image1<br>
2.      Error message:<br>
1.      ERROR: Out of memory in receive_sums [sender]<br>
2.      rsync error: error allocating core memory buffers (code 22) at<br>
<div class="im">util.c(117) [sender=3.0.7]<br>
<br>
I looked at the changelog and haven't seen any updates to util.c since<br>
rsync v3.0.6 was released that might address this issue.  So i think that<br>
I might be seeing two bugs: 1) huge diff size 2) crashing non-gracefully<br>
when trying to use block size with batch mode.<br>
<br>
Has anyone experienced this before, am I allowed to specify block size<br>
with batch mode?  Any words of wisdom?<br>
<br>
Thanks,<br>
</div>Matt Van Mater--<br>
Please use reply-all for most replies to avoid omitting the mailing list.<br>
To unsubscribe or change options:<br>
<a href="https://lists.samba.org/mailman/listinfo/rsync" target="_blank">https://lists.samba.org/mailman/listinfo/rsync</a><br>
Before posting, read: <a href="http://www.catb.org/%7Eesr/faqs/smart-questions.html" target="_blank">http://www.catb.org/~esr/faqs/smart-questions.html</a><br>
<br>
<br>
Please consider the environment before printing this email.<br>
</blockquote></div><br>