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

Feedback for where in the sync queue we currently are #28

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

Feedback for where in the sync queue we currently are #28

GoogleCodeExporter opened this issue Aug 3, 2015 · 6 comments

Comments

@GoogleCodeExporter
Copy link

I'm using lsyncd to sync a great many directories to 6 servers. It's working 
very well for me - thanks!

Sometimes, completing an update can take several hours. It would be really 
useful if there was someway of discovering how many items in the queue still 
have to be synced. For a bonus, an estimate of the time left.

Maybe some kind of status sent to syslog or a local file?

Steve

Original issue reported on code.google.com by cfmshado...@gmail.com on 7 Sep 2010 at 8:57

@GoogleCodeExporter
Copy link
Author

Do you mean initial startup or while normal operation?

Original comment by axk...@gmail.com on 8 Sep 2010 at 5:40

@GoogleCodeExporter
Copy link
Author

I actually meant during normal operation, but I guess the same kind of 
reporting could also be valid for initial startup - but I thought the initial 
sync was just handed off as a single operation? If that's the case then just 
normal operation is what would be really handy.

Thanks for the feedback.

Original comment by cfmshado...@gmail.com on 8 Sep 2010 at 10:33

@GoogleCodeExporter
Copy link
Author

yes, inital startup is just one recursive rsync call.

An ETA is almost close to impossible. I could add a log message tough, how many 
directory/file entries are left in the delay queue.

Are you syning the same directory tree to 6 targets at the same time? In that 
case another change might be of far more importance to you. Currently lsyncd 
waits for one rsync to finish before calling the next. It could however as well 
without any harm to the internal logic call rsync for each target at the same 
time in the case multiple targets are specified for one source branch. Depends 
on where you bottleneck is. If it is your upstream, it wont help much, if it 
isn't it would quite improve performance.

Original comment by axk...@gmail.com on 8 Sep 2010 at 6:21

@GoogleCodeExporter
Copy link
Author

if you check the source in the subversion it now has a "--verbose" option, when 
turned on, it well  tell you on each action how many items are expired or 
delayed. Depending on operation mode this are dirs or files.

Original comment by axk...@gmail.com on 10 Sep 2010 at 7:17

@GoogleCodeExporter
Copy link
Author

Original comment by axk...@gmail.com on 10 Sep 2010 at 7:17

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

@GoogleCodeExporter
Copy link
Author

Original comment by axk...@gmail.com on 4 Oct 2010 at 8:30

  • Changed state: Fixed

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