On Mon, Jun 08, 2026 at 01:59:40PM +0200, Manuel Giraud wrote: > Claudio Jeker <[email protected]> writes: > > > On Mon, Jun 08, 2026 at 10:02:07AM +0200, Manuel Giraud wrote: > >> Thomas de Grivel <[email protected]> writes: > >> > >> > maybe ln -s /usr/bin/openrsync /usr/local/bin/rsync ? > >> > >> Yes of course. My patch was more for a better out of the box behavior. > >> Maybe it could pass tech@? > > > > Right now openrsync is limited in functionality and is primarily present > > for rpki-client. The limited functionality makes it unusable for generic > > use and so any diff or change like the above will not be considered since it > > is simply not ready. > > > > First problem to solve is to remove the mmap usage in openrsync. After > > that modern protocol versions need to be added. Once that is in place one > > can start a discussion about using openrsync as a default on OpenBSD. > > Thanks for these explanations. Why mmap usage should be removed?
Because it is broken, a block is hashed and later pushed. During the time content may change and so the data hashed does not match what is sent. Also try to rsync a file > 4GB on a 32bit arch. It does not work since there is not enough address space for that. The proper way of doing it is to build a block layer that reads a buffer into a block, does the hash and then once the other side decided to need that buffer push it over the wire. Once done with the buffer it can be recycled. This way each block of a file is only read once. There are still issues with concurrent modifications of files during an rsync transfer but those are far less problematic. -- :wq Claudio
