Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very poor performance on syncing deletes #12

Closed
GoogleCodeExporter opened this issue Aug 3, 2015 · 3 comments
Closed

Very poor performance on syncing deletes #12

GoogleCodeExporter opened this issue Aug 3, 2015 · 3 comments

Comments

@GoogleCodeExporter
Copy link

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
Copy link
Author

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
Copy link
Author

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

  • Added labels: Type-Enhancement
  • Removed labels: Type-Defect

@GoogleCodeExporter
Copy link
Author

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

  • Changed state: Wait
  • Added labels: Type-Other
  • Removed labels: Type-Enhancement

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant