Fix for batch mode (was Re: batch mode maintainability)
josb at cncdsl.com
Sat Feb 2 10:49:12 EST 2002
On Fri, Feb 01, 2002 at 02:59:50PM -0600, Dave Dykstra wrote:
> I'm not familiar with that area of the code, but I assume it would be
Good to hear that :)
> Another idea just occurred to me: it would be nice to be able to stream all
> the batch files over the network rather than storing them temporarily on a
> disk, especially on the destinations during a --read-batch operation. That
> could significantly decrease both total elapsed time and disk space usage.
> I think this could even be done with an external program that creates 3
> named pipes or unix-domain sockets on each side and multiplexes the three
> channels together, but it might be better if it were built in.
Sounds like a cool idea...
Again, thanks for the review, technical writing is not one of my forte's. Next
installment of the batch mode doc patch:
RCS file: /cvsroot/rsync/rsync.1,v
retrieving revision 1.108
diff -u -r1.108 rsync.1
--- rsync.1 29 Jan 2002 21:52:56 -0000 1.108
+++ rsync.1 1 Feb 2002 23:50:56 -0000
@@ -306,8 +306,8 @@
--log-format=FORMAT log file transfers using specified format
--password-file=FILE get password from FILE
--bwlimit=KBPS limit I/O bandwidth, KBytes per second
- --read-batch=FILE read batch file
- --write-batch write batch file
+ --write-batch=PREFIX write batch fileset starting with PREFIX
+ --read-batch=PREFIX read batch fileset starting with PREFIX
-h, --help show this help screen
@@ -801,12 +801,14 @@
result is an average transfer rate equalling the specified limit\&. A value
of zero specifies no limit\&.
-Apply a previously generated change batch\&.
-Generate a set of files that can be transferred
-as a batch update\&.
+Generate a set of files that can be transferred as a batch update\&. Each
+filename in the set starts with \fBPREFIX\fP. See the "BATCH MODE" section
+Apply a previously generated change batch, using the fileset whose filenames
+start with \fBPREFIX\fP\&. See the "BATCH MODE" section for details.
.SH "EXCLUDE PATTERNS"
@@ -913,29 +915,80 @@
\fBNote:\fP Batch mode should be considered experimental in this version
of rsync\&. The interface or behaviour may change before it stabilizes\&.
-The following call generates 4 files that encapsulate the information
-for synchronizing the contents of \fBtarget_dir\fP with the updates found in
+Batch mode can be used to apply the same set of updates to many
+identical systems\&. Suppose one has a tree which is replicated on a
+number of hosts\&. Now suppose some changes have been made to this
+source tree and those changes need to be propagated to the other
+hosts\&. In order to do this using batch mode, rsync is run with the
+write-batch option to apply the changes made to the source tree to one
+of the destination trees\&. The write-batch option causes the rsync
+client to store the information needed to repeat this operation against
+other destination trees in a batch update fileset (see below)\&. The
+filename of each file in the fileset starts with a prefix specified by
+the user as an argument to the write-batch option\&. This fileset is
+then copied to each remote host, where rsync is run with the read-batch
+option, again specifying the same prefix, and the destination tree\&.
+Rsync updates the destination tree using the information stored in the
+batch update fileset\&.
+The fileset consists of 4 files:
+<prefix>\fB.rsync_argvs\fP command-line arguments
+<prefix>\fB.rsync_flist\fP rsync internal file metadata
+<prefix>\fB.rsync_csums\fP rsync checksums
+<prefix>\fB.rsync_delta\fP data blocks for file update & change
+The .rsync_argvs file contains a command-line suitable for updating a
+destination tree using that batch update fileset\&. It can be executed using a
+Bourne(-like) shell, optionally passing in an alternate destination tree
+pathname\& which is then used instead of the original path\&. This is useful
+when the destination tree path differs from the original destination tree
+Generating the batch update fileset once saves having to perform the file
+status, checksum and data block generation more than once when updating
+multiple destination trees\&. Multicast transport protocols can be used to
+transfer the batch update files in parallel to many hosts at once, instead of
+sending the same data to every host individually\&.
-$ rsync --write-batch [other rsync options here] \e
+$ rsync --write-batch=some_update [other rsync options] \e
+$ rsync --read-batch=some_update [other rsync options] \e
+The read-batch option expects the destination tree it is meant to update
+to be identical to the destination tree that was used to create the
+batch update fileset\&. When a difference between the destination trees
+is encountered the update will fail at that point, leaving the
+destination tree in a partially updated state\&. In that case, rsync can
+be used in its regular (non-batch) mode of operation to fix up the
+The rsync version used on all destinations should be identical to the one used
+on the original destination\&.
+The -z/--compress option does not work in batch mode and yields a usage
+error\&. A separate compression tool can be used instead to reduce the
+size of the batch update files for transport to the destination\&.
+The -n/--dryrun option does not work in batch mode and yields a runtime
-The generated files are labeled with a common timestamp:
-\fBrsync_argvs\&.<timestamp>\fP command-line arguments
-\fBrsync_flist\&.<timestamp>\fP rsync internal file metadata
-\fBrsync_csums\&.<timestamp>\fP rsync checksums
-\fBrsync_delta\&.<timestamp>\fP data blocks for file update & change
-See \fBhttp://www\&.ils\&.unc\&.edu/i2dsi/unc_rsync+\&.html\fP for papers and technical
+See \fBhttp://www\&.ils\&.unc\&.edu/i2dsi/unc_rsync+\&.html\fP for papers and
.SH "SYMBOLIC LINKS"
Jos Backus _/ _/_/_/ Santa Clara, CA
_/ _/ _/
_/ _/ _/ _/
josb at cncdsl.com _/_/ _/_/_/ use Std::Disclaimer;
More information about the rsync