Re: default value for --compress-level

2010-09-15 Thread Benjamin R. Haskell

On Tue, 14 Sep 2010, Tomasz Chmielewski wrote:


What is the default value for --compress-level=? 6? 9?

The fine manual only mentions:

  --compress-level=NUM
 Explicitly set the compression level to use (see
 --compress) instead of letting it default.  If NUM is
 non-zero, the --compress option is implied.


Also, what are allowed values? 1-9? 0-9? Something else?



From a comment in zlib/zlib.h in the source:



The compression level must be Z_DEFAULT_COMPRESSION, or between 0 and 9: 
1 gives best speed, 9 gives best compression, 0 gives no compression at 
all (the input data is simply copied a block at a time). 
Z_DEFAULT_COMPRESSION requests a default compromise between speed and 
compression (currently equivalent to level 6).



Z_DEFAULT_COMPRESSION is defined as (-1), and appears to be the value 
used if --compress is specified without --compress-level, making the 
default functionally equivalent to 6.


--
Best,
Ben
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


What is the block size algorithm

2010-09-15 Thread Renaud Pelissier
Hello,

First of all, thank you for this great software of rsync. If is extremely
flexible and powerfull.
(my only regret is that i could not find a version for windows dealing
properly with charsets in the files' name, might be patched in a future
version of cygwin? anyway this is not the subject here [?]).

I would like to know how, in the version 3, is computed the default
Block-Size?
I found an old post about this saying it was :

The closest 2^k approximation of N/10 000, and inside the range 700 - 16
 384.


But running a test on version 3,  I computed an estimate of the block size
for a 1.9Go file:

N = 1 950 368 768
 Received = 310 851
 AvBlockSigSize ~= 8.09 Byte/Block (from some other tests i made)

*BlockSize = 310 851 / 8.09 ~= 38 424*


So 38 424 is not in the range and is not far from sqrt(N)?

Could anyone tell me what is the actual implementation in the last release
of Rsync?

Best regards,

Renaud
330.gif-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Intermittent rsync Issues

2010-09-15 Thread J. T. Gray
Greetings,

I posted this to a couple online forums already am am already doubting
anyone will be able to directly help me solve my problems.  So I am here to
query the experts directly:

 I have a number of rsync clients trying to connect to an rsync server
 routinely, and they're intermittently failing with one of a couple error
 messages.

 Either:

 2010/09/15 13:45:23 [32143] rsync: connection unexpectedly closed (0 bytes
 received so far) [Receiver] 2010/09/15 13:45:23 [32143] rsync error:
 unexplained error (code 255) at io.c(601) [Receiver=3.0.7]

 Or:

 2010/09/15 13:40:01 [7617] rsync: connection unexpectedly closed (0 bytes
 received so far) [Receiver] 2010/09/15 13:40:01 [7617] rsync error: error in
 rsync protocol data stream (code 12) at io.c(601) [Receiver=3.0.7]

 The current version of the rsync command I'm using is:

 rsync --rsync-path=/usr/bin/rsync --stats --compress --times --links
 --log-file=/home/ubuntu/rsynclog.txt --exclude thatfile --recursive
 xxx.xx.xxx.xx:/home/ubuntu/utility_scripts/ /home/ubuntu/utility_scripts 

 I previously had --verbose and --progress but removed them after reading on
 another forum that someone had resolved some latency issues by removing
 those options. I've also tried this command in the form of a shell script,
 thinking perhaps the issue was that my rsync client was attempting to reuse
 an expired ssh connection. To that end, it fails seemingly at random whether
 using rsh or ssh. It periodically fails whether or not I do --del or
 --delete, --compress or not, --rsync-path or not.

 I cannot get the command to fail from the command line, but when it runs
 every minute, it fails 5-15 times an hour, depending on the directory being
 rsync'ed. The permissions and ownership appear to all be correct, and I'm
 not relying on any sort of environmental variables that would be causing the
 cron to fail. All of the relevant software packages (bash, rsync, ssh,
 Linux) are up to date, all key ports are open, and all clients do not fail
 simultaneously, suggesting this is not a server-side problem.

If anyone has any constructive feedback for resolving or troubleshooting
this/these issue/s, I am very interested in hearing it.

Thanks,
JTG
-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Intermittent rsync Issues

2010-09-15 Thread Henri Shustak

 I posted this to a couple online forums already am am already doubting anyone 
 will be able to directly help me solve my problems.  So I am here to query 
 the experts directly:
 I have a number of rsync clients trying to connect to an rsync server 
 routinely, and they're intermittently failing with one of a couple error 
 messages.
 
 Either:
 
 2010/09/15 13:45:23 [32143] rsync: connection unexpectedly closed (0 bytes 
 received so far) [Receiver] 2010/09/15 13:45:23 [32143] rsync error: 
 unexplained error (code 255) at io.c(601) [Receiver=3.0.7]
 
 Or:
 
 2010/09/15 13:40:01 [7617] rsync: connection unexpectedly closed (0 bytes 
 received so far) [Receiver] 2010/09/15 13:40:01 [7617] rsync error: error in 
 rsync protocol data stream (code 12) at io.c(601) [Receiver=3.0.7]
 
 The current version of the rsync command I'm using is:
 
 rsync --rsync-path=/usr/bin/rsync --stats --compress --times --links 
 --log-file=/home/ubuntu/rsynclog.txt --exclude thatfile --recursive 
 xxx.xx.xxx.xx:/home/ubuntu/utility_scripts/ /home/ubuntu/utility_scripts 
 
 I previously had --verbose and --progress but removed them after reading on 
 another forum that someone had resolved some latency issues by removing those 
 options. I've also tried this command in the form of a shell script, thinking 
 perhaps the issue was that my rsync client was attempting to reuse an expired 
 ssh connection. To that end, it fails seemingly at random whether using rsh 
 or ssh. It periodically fails whether or not I do --del or --delete, 
 --compress or not, --rsync-path or not.
 
 I cannot get the command to fail from the command line, but when it runs 
 every minute, it fails 5-15 times an hour, depending on the directory being 
 rsync'ed. The permissions and ownership appear to all be correct, and I'm not 
 relying on any sort of environmental variables that would be causing the cron 
 to fail. All of the relevant software packages (bash, rsync, ssh, Linux) are 
 up to date, all key ports are open, and all clients do not fail 
 simultaneously, suggesting this is not a server-side problem.
 
 If anyone has any constructive feedback for resolving or troubleshooting 
 this/these issue/s, I am very interested in hearing it.


Typically how long will the command take to execute?

You could add the 'time' command before rsync to find out.

Hope this helps.


-
This email is protected by LBackup, an open source backup solution.
http://www.lbackup.org


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html