Phil has some good suggestions here for rsync usage. Have a look...it'll
most likely help your ISO syncs as well as the distribution tree syncs.
----- Forwarded message from phil@ipal.net -----
From: phil@ipal.net
Subject: Re: [slackware-sparcdevel] rsync server
To: david@slackware.com
Date: Wed, 1 Nov 2000 17:39:27 -0600 (CST)
In-Reply-To: <20001101091941.A28210@slackware.com> from "David Cantrell" at Nov 01, 2000 09:19:41 AM
X-Mailer: ELM [version 2.5 PL0pre8]
> Rsync access has been reopened. The password for the private beta-tester
[snip]
I'm sending this not to the list since I don't know if you want to have
everyone using this feature, although I really don't see why not since it
cuts bandwidth usage. If you want to pass the stuff below to the list,
please feel free to do so.
If the rsync checksum option (-c, --checksum) is on, rsync will do checksums
on the files being syncronized. It does this checksum on individual data
blocks within the file and is capable of transferring only those parts of a
file which have changed. It may even be able to handle files where data
blocks move around a little bit but I have not confirmed this for certain.
I'll test this later on to be sure but this is easy enough to implement with
a hash so I would be kind of surprised if it doesn't handle it.
For an ISO image, the default rsync blocksize of 700 bytes (I have no idea
why that number was chosen) is not optimal. The better size to choose on
the rsync blocksize option (-B, --block-size=SIZE) is 2048 since this is the
allocation unit of the ISO-9660 format. Data blocks of individual unchanged
files within the ISO filesystem will either be, or not be, there in 2048
byte units.
I just reran rsync manually on the ISO. It transferred only 42,750,646
bytes (why that isn't an exact multiple of 2048 is probably because it
includes protocol overhead such as the checksums) and matched 380,952,576
bytes from the previous file. I would think this is a good thing and 2048
bytes is the preferred blocksize choice. Debian's psuedo-image-kit says
to use 8192, but I think that's not quite the right choice, unless it
reduces the number of checksums sent and blocks requested (it won't reduce
the CPU utilization for checksumming). If a file in the ISO shifts by a
mere 2048, or 4096, or 6144 bytes, using a blocksize of 8192 will see that
part of the ISO as entirely changed.
IMHO, people should be doing rsync this way for ISOs.
-- | Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org | phil (at) ipal.net +---------------------------------------------------- | Dallas - Texas - USA | phil-evaluates-email-ads-750-dollars-each@ipal.net----- End forwarded message -----
-- David Cantrell | david@slackware.com KG6CII | Slackware Linux Project
This archive was generated by hypermail 2b30 : Thu Sep 19 2002 - 11:00:02 PDT