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..
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html