If the batchSizeLimit is set, only files lower then this limit will
be grouped in one rsync transfer.
Each file larger then this limit will spawn their own transfer process.
This will cause large files to no longer block small file transfers under the
circumstance the maxProcess limit on the sync is larger then 1
A very optimized, very secure transfer configuration based on a
pool of ssh connection looks like this:
```
sync {
default.rsync,
tunnel = tunnel {
command = {"ssh", "-N", "-L", "localhost:${localport}:localhost:873", "user@targetmachine"},
mode = "pool",
parallel = 2,
},
source = "/tmp/src",
target = "rsync://localhost:${localport}/test",
delay = 5,
batchSizeLimit = 1024 * 1024 * 30,
maxProcesses = 4,
rsync = {
verbose = true,
inplace = true,
}
}
```
If you configure remote ssh configuration only allows portforwarding and your rsync daemon
is configured correctly, you can very securely transfer data without giving shell access.
In this mode, multiple tunnel processes are started and connection a load
balanced on the pool of connections.
Example config:
...
sync {
default.rsync,
tunnel = tunnel {
command = {"ssh", "-N", "-L", "localhost:${localport}:localhost:873", "user@testmachine"},
mode = "pool",
parallel = 2,
},
target = "rsync://localhost:${localport}/test",
...
}
This option can't be added to both init and action, because the rsync
exclude mechanism is used to select the files to send, so would delete
all non-changed files. It's only relevant during init anyway, as after
that no excluded files will be made on the destination.
As per the rsync docs: "This tells rsync to copy the referent of symbolic links that point outside the copied tree. Absolute symlinks are also treated like ordinary files, and so are any symlinks in the source path itself when --relative is used. This option has no additional effect if --copy-links was also specified."
