Nulls instead of data
Wayne Davison
wayned at samba.org
Thu Sep 22 15:40:35 GMT 2005
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..
More information about the rsync
mailing list