[Csync2] speed of "-cr /"

[Aristedes Maniatis]

On 11/06/10 7:44 PM, Lars Ellenberg wrote:

> First time you mention groups.

I had not thought they were relevant to the questions I had.

> If you had been less assumptious, less accusing, less ranting about what
> does not work and how stupid the rest of the world is,

Ah, what? I take exception to that. I've done none of these things. I've been asking purely technical questions about its operation. Perhaps you are confusing me with someone else?

You have generously provided an open source tool. You certainly aren't under any obligation to help users with the tool (although it does create a community of users). But your responses have been pretty curt:

On 9/06/10 9:41 PM, Lars Ellenberg wrote:
> Let me repeat myself:
>
> Csync2 does already what you ask for.
> (Even if it seems to you that it may not).

In each case I've been civil and tried to supply you with the necessary information.



> but more precise about what you are doing, and included your conf file
> right away (instead of just one single include line in some followup),
> you could have been here a few days ago ;-)

I've deliberately not included a 100 line config file in my original question because I wanted to focus on the specifics of my question.


> Csync2 does two scans:
>   it checks for deletions, basically select filenam from file,
>     is filename still present?  no->  mark as dirty.
>   it checks for modifications (including additions), basically
>     scanning directories, comparing with database entries.
>
> If you don't explicitly state "-G ", csync2 defaults to all groups.
>
> But even if you do "-G single_entry_group", that currently optimizes
> only the "check for modifications/additions".
>
> The "check for deletions" currently does not care for groups.

I'd go one step further: your check for deletions step doesn't respect includes/excludes. Whether that be for a particular group, or for the entire configuration (and you haven't run -R recently to clean up lots of stale files).



> If different configs had been supported from the very start,
> groups probably had not been invented in the first place.
>
>> I'd rather not create a dozen config files with a dozen databases.
>
> Why not?

Because I'd need a dozen daemons listening on every server. And because the documentation led me to believe that groups were the way to approach the problem of having several configurations. Until now I was not aware of the limitation of performance speed when arranging the configuration using groups rather than separate files.


> Converting your truely independent groups with many files each
> into their own configs instead seems to be a good idea,
> even just from a sqlite maintenance, performance, and congestion
> point of view.
>
> I don't see why it would pose an administration overhead, either.

Personally I like the ease of editing a single file. And it also means that I can run a single command to update all the groups, or even just pass a list of groups on the command line to they all get executed by the one script. If I have to worry about multiple listeners, ports and so forth there is a little more work to do.

I'll consider it now that I understand the limitations of 'groups' in csync2.


Ari

  

-- 
-------------------------->
Aristedes Maniatis
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A