Re: rsync 2.6.6 : Possible comms failure during delete backup of
This is a discussion on Re: rsync 2.6.6 : Possible comms failure during delete backup of within the Rsync forums, part of the Networking and Network Related category; --===============1616628185== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
09-20-2005
|
|||
|
|||
Re: rsync 2.6.6 : Possible comms failure during delete backup of
--===============1616628185==
Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Wayne Davison wrote: <blockquote cite="mid20050911173952.GA10790@blorf.net" type="cite"> <pre wrap="">On Thu, Sep 08, 2005 at 01:39:39PM +1000, Mark Inkley wrote: </pre> <blockquote type="cite"> <pre wrap="">You will note, that I am using 2.6.6, previously I used 2.6.2 which had the same issues. </pre> </blockquote> <pre wrap=""><!----> Is the version on each machine 2.6.6? </pre> </blockquote> Yes, I am using the -rsync-path switch to target the 2.6.6 binary. Our binaries are on AFS so this is pretty easy to do.<br> <br> <blockquote cite="mid20050911173952.GA10790@blorf.net" type="cite"> <pre wrap="">If the remote version is older than 2.6.4 then rsync cannot use its keep-alive protocol to try to keep the connection from timing out during lulls in the sending of data (such as when one side is busy deleting files). (Also, 2.6.4 only has partial keep-alive support.) If both machines are running 2.6.6, it is still possible for the session to timeout if the keep-alive logic doesn't get called often enough for the speed of your system and the largeness of the files involved (e.g. a local copy of a large file that can occur when backing up deleted files can slow down the checking). In such situations, a workaround is to slightly increase the timeout value to avoid the accidental triggering. </pre> </blockquote> I must admit, playing with the timeouts did not produce the desired results. I have found a vast improvement by using the -delete-during option, and now we have a much higher sucess rate of jobs completing (100% so far) and it seems to take less time to run. I would have liked to use the delete-after switch only because in some cases this reduces process time on the source and makes for a shorter work-window on the source. However the timeout problem still exists.<br> <blockquote cite="mid20050911173952.GA10790@blorf.net" type="cite"> <pre wrap="">Yes, the keep-alive logic in rsync could be improved to help it avoid such extended lull sections, so if someone wants to look into this, feel free. ...wayne.. </pre> </blockquote> <br> </body> </html> --===============1616628185== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html --===============1616628185==-- 
|
Linear Mode
