Nulls instead of data

[Wayne Davison]

On Thu, Sep 22, 2005 at 09:35:52AM +0200, Wojtek.Pilorz wrote:
> #define MAX_MAP_SIZE (256*1024)
> which values should I change to have e.g. 24KBytes in one read, if that is possible?

The sender code reads at least 3x the file's block size or MAX_MAP_SIZE,
whichever is larger.  So, making MAX_MAP_SIZE small would make rsync
tend to ask for less data, but with large files, it could still ask for
a lot.  If you want to limit the most that a read can ask for, edit the
map_ptr() code in fileio.c (indentation has been compressed):

  while (read_size > 0) {
    int32 rsz = read_size > 24*1024 ? 24*1024 : read_size; /* add this line */
    nread = read(map->fd, map->p + read_offset, rsz); /* change read_size to rsz */
    if (nread <= 0) {
      [...]

This presumes that my prior patch is applied (which is true of the CVS
code, and the latest "nightly" builds).

> Was that expected that after unsuccessful read (that one with EIO)
> data was still written by the process, with nulls from some point?

Yes, that's what rsync currently does -- it fills in the unreadable data
with nulls.  The current rsync protocol is too limited to have a way to
specify an "abort" after the start of a file transfer.  Note that if
--partial is used, the data is preserved as the destination file, but
the file's time is not updated (so that it will not be confused with a
successfully transferred file).  If --partial-dir=DIR is used, the file
will be put out of the way, but available for use to speed up the next
transfer (if it uses the same --partial-dir setting).

..wayne..