map_ptr() handles read failures by zeroing out remaining chunk and returning the partially filled/all zero buffers to callers. It also fills error details in map_struct->status.
It is caller's responsibility to check the status and handle this condition appropriately.
It is probably OK to ignore this when we are generating checksums (as it might lead to a false mismatch, resulting in transfer of a non matching block)
But in context of transfer (send_deflated_token()) when this error is ignored it leads to silent data corruption for receiver.
Possible solutions are to log errors and disconnect such connection, or retry till timeout happens.
No point in giving user a false impression that xfr is successful. Request dev to look at it with priority.
Cheers,
Ankur

(In reply to comment #1)
> Rsync marks a file with a read error with a checksum that doesn't match the
> file content so that the receiver knows that the file it generated is not
> valid.
Thanks for your response Wayne. Apologies for long comment below, but it would be really helpful if you could go through it.
My setup is rsyncd on one machine (source of a file), and rsync client on another machine (destination).
When this happens (checksum mismatch due to read failure) does receiver (destination) throw an error? What I see is that receiver is not retuning an error code. From receiver point of view this looks like a success.
I have tested this with both with and without --checksum with fresh sync (i.e., receiver didn't have the file)
This is the experiment I did:
1. Ran rsyncd on one machine
2. Modified the rsyncd map_ptr() to mimic read failures
3. Ran rsync from a different machine
4. I could see rsync returning without any error, and a partially zeroed out file (of same length)
5. I observed same symptoms as #4 on a flash based embedded system during i/o stress on server side.
Is there any specific option I should be using while running rsync to catch checksum errors?
Thanks,
Ankur