1.3.0-RC-6 Image replication calculation error
-
Hi Tom/Wayne,
Just installed RC-6. The image replication calculation is still slightly out for local file sizes. Local file sizes are all showing up as 8 bytes smaller than the remote file sizes, so will loop on all files now. See attached log screenshot.
Regards, Mark
-
https://github.com/FOGProject/fogproject/commit/9f6bc26eb9fd0a61cd0cc789375d418437bbc4e0
Can you try the fogservice.class.php patch in the attached link? Because we’re changing the information into essentially a string form, the values won’t “exactly” match.
-
Moved to bug reports.
-
@Wayne-Workman Sorry I should have put it directly in here. Unfortunately a fix didn’t make it into RC-7. Roll on RC-8!
-
https://github.com/FOGProject/fogproject/commit/0c91150121ed3b6483527f8f15d8e8e7a1b6bbaf
Can you please try applying that patch to your RC-7 installation? Apparently I mistook an 8 where it should’ve been a 0. Hopefully, with that minor change (and your testing confirming if this fixes it, we can close this bug report.
I’m sorry I missed it for RC-7.
-
@Tom-Elliott Have tried the patch. The numbers add up now, but it is still saying “Files do not match” and writing over them repeatedly. I tried to upload an image of the log but don’t have privileges to upload on this thread.
-
https://github.com/FOGProject/fogproject/commit/9f6bc26eb9fd0a61cd0cc789375d418437bbc4e0
Can you try the fogservice.class.php patch in the attached link? Because we’re changing the information into essentially a string form, the values won’t “exactly” match.
-
We have run-away replication happening at our organization now, same issue here.
I have to stop the fog image replicator completely.
This bug should be top priority.
-
@Wayne-Workman I believe Tom’s latest patch has fixed the issue. I wont know for certain until the largest file has replicated which will take a couple of days, but the others match now and the largest file local size is accurate, so I’m quietly confident.
-
@Tom-Elliott I think this latest patch fixed the issue. The smaller file sizes match and the local size of the largest file is now accurate, so I anticipate when fully replicated the large files will also match. I’ll let you know. Thanks Tom.
-
the fixes in rc-8 do fix it, I’ve confirmed them as you have.
-
I’ve marked the thread as solved so as to ensure I don’t go crazy looking at “unsolved” threads. RC-8 will have the fix for the replication issues as well as a few other fixes that were rather not issues (in the directest sense of the word) but just redundant.
The additional fixes just ensure that if all files are matching, it doesn’t try to resync the data between the two sides (causing unnecessary load – if only for a second or two).
A part of the “whole” is it will also enable ALL services to update their loop update times properly. Only MulticastManager had been working properly apparently, not that many would’ve noticed a serious issue. It will properly check the new sleep times and start using the new sleeptime after the next cycle runs (if it isn’t already running).
For example, say your FOGMulticastManager is setup to go in 10 second intervals (which is the default) and you want FOGMulticastManager to go in 300 second (5 minute) intervals, if you updated the FOGMulticastManager sleeptime to use 300, it will update after the next check, or when this current check is complete.