solotimes / lsyncd

Automatically exported from code.google.com/p/lsyncd
GNU General Public License v2.0
0 stars 0 forks source link

Very poor performance on syncing deletes #12

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Recursively delete some files
2. Watch the log as lsyncd tries to rsync files that are no longer there
3. Takes forever - the more that was deleted, the longer it takes

What is the expected output? What do you see instead?

I would expect that lsyncd would at least do a stat on the file to see if
it existed before trying to rsync it.  Obviously if it is not there, lsyncd
should discard the sync and move on to the next inotify event - eventually
the event containing the correct sync level will get hit and rsync can then
be triggered.  This would be MUCH faster.

What version of the product are you using? On what operating system?

lsync 1.26 / rsync  version 3.0.6  protocol version 30
2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 16:12:36 EST 2009 x86_64 x86_64 x86_64
GNU/Linux

Please provide any additional information below.

File creation or updates work great - just deletes where the problem seems
to be limited.

Original issue reported on code.google.com by caffeine...@gmail.com on 25 Nov 2009 at 7:47

GoogleCodeExporter commented 9 years ago
The attached diff seems to solve the problem - delete performance when deleting 
lots
of files is GREATLY increased in my tests.  Please let me know if you see any 
issues.

Original comment by caffeine...@gmail.com on 28 Nov 2009 at 12:20

Attachments:

GoogleCodeExporter commented 9 years ago
I'm not yet entirly sure which deletes can be omited so we never miss one. 

@caffeiniejolt I'm refusing that patch sorry, as far as I see it introduces 
memleaks.

Original comment by axk...@gmail.com on 11 Jul 2010 at 7:51

GoogleCodeExporter commented 9 years ago

Original comment by axk...@gmail.com on 20 Jul 2010 at 10:57