Lars- I see it's not so far off, but definitely not a drop-in replacement (already ran into some problems). It worries me to make so many changes to a system that's been working so well for so long... is there really no hope for getting file-specific syncs working with prefixes in 1.34?
I'm also worried that it still might not work even if I do... I took a good long look at the source code for both versions. In csync_update_host(), there's a line that seems to me will always be false, leading to no update: if ( compare_files <http://sourcecodebrowser.com/csync2/1.34/update_8c.html#a405f4be2b99d5da4363abb4b8348c16b>(filename, patlist[i], recursive) ) use_this = 1; My understanding is that filename is as it's listed in the database, which for a config with prefix, will include the prefix (eg: "%FSROOT%/test1"). Isn't patlist[i] simply the filename as passed on the command line? (eg: "/path/to/test1") It doesn't appear that compare_files() takes into account the prefix. If so, won't such a compare_files() call always return 0? (resulting in no update) [http://codepad.org/mYtUB4o7] btw- the relevant code appears to be the same in 2.0 as in 1.34. If so, specifying the file on the command line in a configuration with a prefix still won't work... can someone on this list having a prefix config (using either version) confirm that specifying the filename on the command line triggers an update? Note that csync_check() clearly substitutes the prefix, but I don't see where such a substitution happens for updates. Am I wading in too deep? On Tue, Jul 8, 2014 at 8:37 AM, dlo <csy...@dlopez.com> wrote: > Is it definitely a drop-in replacement? (db format is the same, etc.?) > > The main csync2 page didn't give me confidence in 2.0, since it has RC > next to it, and I didn't see a changelog. In one of the original messages > on this list about 2.0, you even mention something about inotify and > support for other databases, which also worried me that things were very > different... though the current PDF and man page don't seem very different. > > > On Tue, Jul 8, 2014 at 6:06 AM, Lars Ellenberg <lars.ellenb...@linbit.com> > wrote: > >> On Tue, Jul 08, 2014 at 04:31:46AM -0400, dlo wrote: >> > I've had csync2 (1.34) working fine for a few years now... it took a >> bit of >> > work to figure out its quirks, but it's been really great and reliable. >> > (Thank you, Lars et al!) >> >> Please try 2.0, if you can. >> >> > On one of my machines (rs1), I'm running out of space on the partition >> > containing the synced folder, so I changed the configuration to use >> > prefixes, so that the other server (rs2) continues with its normal path, >> > and the space-limited server is using a new disk. The prefix is the >> only >> > thing I changed from the previously working configuration. >> > >> > ... >> > > include %FSROOT%/; >> > > ... >> > > prefix FSROOT >> > > { >> > > on rs1: /mnt/cbsvol3/files; >> > > on rs2: /home/myuser/folder/files; >> > > } >> > >> > >> > Not knowing how to update the database to reflect the new path, I >> manually >> > changed the filename values in the file table in sqlite on both >> servers. I >> > was nervous about this, but it seems to have worked ok. For example: >> > INSERT INTO file >> > >> VALUES('/home/myuser/folder/files/trg','v1%3Amode=16872%3Auid=12036132%3Agid=19232%3Atype=dir'); >> > became >> > INSERT INTO file >> > >> VALUES('%25FSROOT%25/trg','v1%3Amode=16872%3Auid=12036132%3Agid=19232%3Atype=dir'); >> > >> > Good news: When I run a full sync (csync2 -rx), it works absolutely >> fine. >> > >> > Bad news: However, if I run a sync of a specific file, which is >> necessary >> > for my use case (with lsyncd, though at this point I'm testing it >> > manually), it appears to mark the file as dirty, but does not actually >> > sync. Using verbose mode seems to indicate that it is not even >> attempting >> > to connect to its peer: >> > >> > rs1% /usr/sbin/csync2 -C test -xvv test3 >> > > My hostname is rs1. >> > > Database-File: /var/lib/csync2/rs1_test.db >> > > Config-File: /etc/csync2_test.cfg >> > > Prefix 'FSROOT' is set to '/mnt/cbsvol3/files'. >> > > Match (+): %FSROOT% on %FSROOT%/test3 >> > > Running check for /mnt/cbsvol3/files/test3 ... >> > > SQL: SELECT filename from file where filename = >> '/mnt/cbsvol3/files/test3' >> > > ORDER BY filename >> > > SQL Query finished. >> > > Don't check at all: /mnt/cbsvol3/files/test3 >> > > Running check for %FSROOT%/test3 ... >> > > SQL: SELECT filename from file where filename = '%25FSROOT%25/test3' >> > > ORDER BY filename >> > > SQL Query finished. >> > > Match (+): %FSROOT% on %FSROOT%/test3 >> > > Checking %FSROOT%/test3. >> > > SQL: SELECT checktxt FROM file WHERE filename = '%25FSROOT%25/test3' >> > > SQL Query finished. >> > > SQL: SELECT peername FROM dirty GROUP BY peername ORDER BY random() >> > > SQL Query finished. >> > > SQL: SELECT filename, myname, force FROM dirty WHERE peername = 'rs2' >> > > ORDER by filename ASC >> > > SQL Query finished. >> > > SQL: SELECT command, logfile FROM action GROUP BY command, logfile >> > > SQL Query finished. >> > > Finished with 0 errors. >> > >> > >> > Likewise, if I run with -T on all, the results seem accurate; however, >> if I >> > run -T on the one changed file, it does actually connect to the peer, >> but >> > doesn't seem to get a sig on the file, and ultimately returns nothing. >> I'm >> > a bit confused about whether maybe the remote host is querying using the >> > local host's prefix path? (and if so, what to do to fix it?): >> > >> > > rs1% /usr/sbin/csync2 -C test -Tvvv test3 >> > > My hostname is rs1. >> > > Database-File: /var/lib/csync2/rs1_test.db >> > > Config-File: /etc/csync2_test.cfg >> > > Prefix 'FSROOT' is set to '/mnt/cbsvol3/files'. >> > > Match (+): %FSROOT% on %FSROOT%/test3 >> > > Running in-sync check for rs1 <-> rs2. >> > > Connecting to host rs2 (SSL) ... >> > > Local> SSL\n >> > > Peer> OK (activating_ssl).\n >> > > SQL: SELECT certdata FROM x509_cert WHERE peername = 'rs2' >> > > SQL Query finished. >> > > Peer x509 certificate is: [...] >> > > Local> CONFIG test\n >> > > Peer> OK (cmd_finished).\n >> > > Local> HELLO rs1\n >> > > Peer> OK (cmd_finished).\n >> > > Local> LIST rs2 /mnt/cbsvol3/files/test3 >> > > Local> >> sF9HeaK6kuFzNfkPgTjL6wcY9akx2_pjjAg1.VOqYHG9AgLjzEG1zfttMlt9WLrp >> > > Local> \n >> > > SQL: SELECT checktxt, filename FROM file WHERE filename = ' >> > > /mnt/cbsvol3/files/test3' ORDER BY filename >> > > SQL Query finished. >> > > Peer> OK (cmd_finished).\n >> > > End of query results: OK (cmd_finished). >> > > Local> BYE\n >> > > Peer> OK (cu_later).\n >> > > SQL: SELECT command, logfile FROM action GROUP BY command, logfile >> > > SQL Query finished. >> > > Finished with 0 errors. >> > >> > >> > After many hours, I'm at a loss... do you have any additional ideas for >> me >> > to try? This isn't a bug, is it? >> >> > _______________________________________________ >> > Csync2 mailing list >> > Csync2@lists.linbit.com >> > http://lists.linbit.com/mailman/listinfo/csync2 >> >> >> -- >> : Lars Ellenberg >> : LINBIT | Your Way to High Availability >> : DRBD/HA support and consulting http://www.linbit.com >> >> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. >> _______________________________________________ >> Csync2 mailing list >> Csync2@lists.linbit.com >> http://lists.linbit.com/mailman/listinfo/csync2 >> > >
_______________________________________________ Csync2 mailing list Csync2@lists.linbit.com http://lists.linbit.com/mailman/listinfo/csync2
