alonjr

@Helen, Upgrading to the latest btsync version fixed the issue. I'm happy as clam! (this is regarding my issue at the top of this thread)

Setup I have the latest BTSync running on two headless-linux devices. The two devices are linked; Device A is located in my home while device B is a virtual server in some datacenter. Device A generates approx. 50 images (100Kb each) on a regular basis (45 mins on average) and stores those under a new sub-directory; At the same time, it creates a static symbolic link which points to the new images directory just created. Issue Observed All files are synced from device A to B as expected. However very often, the files that were added are unexpectedly removed from device

I have a similar case where btsync is killed because of oom - see segment below from /var/log/messages. The *.db file is 631Mb in size and it is NOT corrupt (I checked using @rdebath sqlite3 test above). Any ideas what other checks and test I can do to identify the issue? My setup is a Raspberry Pi, Synced 49GB in 307418 files, and I don't seem to have an issue disk space issues. Thanks Nov 4 16:47:02 sync kernel: [ 3500.806921] btsync invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0Nov 4 16:47:02 sync kernel: [ 3500.806960] CPU: 0 PID: 2199 Comm: btsync Not tainted 3.12.

BTsync is drawing quite a lot of CPU resources from my Raspberry Pi (currently I have approx. 97k files that total 15GB and I expect that to double before it plateaus). Based on other articles in this forum, i'm considering to increase the folder_rescan_interval to be a much higher number. Here comes my question ... The Raspberry Pi simply serves as a Read-Only device, in other words, no files will be changing on this device, it only servers to mirror a folder contents on another (ubuntu) device that frequently creates new files (photos). In this scenario, is folder rescan even necessa