andoma
-
Posts
6 -
Joined
-
Last visited
Posts posted by andoma
-
-
I'm having the same issue. It's using a lot more CPU on idle, and I'm running it on ubuntu intel 64 bit.
I've the same problem. Monitoring about 100k files though. Not sure if this is too much for btsync? Maybe it is and I need to look into other alternatives.
-
btsync keeps crashing on my linux machine$ uname -aLinux skytown 3.15.0-031500rc4-generic #201405042135 SMP Mon May 5 01:36:35 UTC 2014 x86_64 x86_64 x86_64 GNU/LinuxAny additional info I can provide?[1002841.588262] traps: btsync[28365] trap divide error ip:4d18bf sp:7f7be5734dc0 error:0 in btsync[400000+3df000][1002841.770462] init: btsync main process (28359) killed by FPE signal[1002841.770478] init: btsync main process ended, respawning[1002876.708243] traps: btsync[28450] trap divide error ip:4d18bf sp:7f91b6212dc0 error:0 in btsync[400000+3df000][1002876.890650] init: btsync main process (28444) killed by FPE signal[1002876.890672] init: btsync main process ended, respawning[1002911.664913] traps: btsync[28536] trap divide error ip:4d18bf sp:7f02367bedc0 error:0 in btsync[400000+3df000][1002911.843780] init: btsync main process (28530) killed by FPE signal[1002911.843796] init: btsync main process ended, respawning[1002967.037544] traps: btsync[28618] trap divide error ip:4d18bf sp:7fe515397dc0 error:0 in btsync[400000+3df000][1002967.218573] init: btsync main process (28611) killed by FPE signal[1002967.218589] init: btsync main process ended, respawning[1003012.261656] traps: btsync[28745] trap divide error ip:4d18bf sp:7fb54b2aedc0 error:0 in btsync[400000+3df000][1003012.444918] init: btsync main process (28739) killed by FPE signal[1003012.444935] init: btsync main process ended, respawning[1003062.164085] traps: btsync[28853] trap divide error ip:4d18bf sp:7f913ca52dc0 error:0 in btsync[400000+3df000][1003062.344367] init: btsync main process (28847) killed by FPE signal[1003062.344383] init: btsync main process ended, respawning[1003112.232984] traps: btsync[28971] trap divide error ip:4d18bf sp:7f7d0c1f7dc0 error:0 in btsync[400000+3df000][1003112.414854] init: btsync main process (28965) killed by FPE signal[1003112.414877] init: btsync main process ended, respawning[1004926.800941] traps: btsync[29087] trap divide error ip:4d18bf sp:7f818fe90dc0 error:0 in btsync[400000+3df000][1004926.993142] init: btsync main process (29081) killed by FPE signal[1004926.993158] init: btsync main process ended, respawning[1004946.570240] traps: btsync[600] trap divide error ip:4d18bf sp:7f52a6d47dc0 error:0 in btsync[400000+3df000][1004946.749272] init: btsync main process (594) killed by FPE signal[1004946.749289] init: btsync main process ended, respawning[1004966.675878] traps: btsync[651] trap divide error ip:4d18bf sp:7f2a18486dc0 error:0 in btsync[400000+3df000][1004966.855516] init: btsync main process (645) killed by FPE signal[1004966.855539] init: btsync main process ended, respawning[1004986.772559] traps: btsync[705] trap divide error ip:4d18bf sp:7f00a5d03dc0 error:0 in btsync[400000+3df000][1004986.950406] init: btsync main process (699) killed by FPE signal[1004986.950422] init: btsync main process ended, respawning[1005031.620291] traps: btsync[759] trap divide error ip:4d18bf sp:7f0d8ef34dc0 error:0 in btsync[400000+3df000][1005031.807072] init: btsync main process (753) killed by FPE signal[1005031.807089] init: btsync main process ended, respawning[1005071.758530] traps: btsync[871] trap divide error ip:4d18bf sp:7ff69ef68dc0 error:0 in btsync[400000+3df000][1005071.939333] init: btsync main process (865) killed by FPE signal[1005071.939349] init: btsync main process ended, respawning[1041666.754471] traps: btsync[975] trap divide error ip:4d18bf sp:7f21f6434dc0 error:0 in btsync[400000+3df000][1041666.923950] init: btsync main process (969) killed by FPE signal[1041666.923967] init: btsync main process ended, respawning[1041691.843616] traps: btsync[18650] trap divide error ip:4d18bf sp:7fcad8ff3dc0 error:0 in btsync[400000+3df000][1041692.019058] init: btsync main process (18644) killed by FPE signal[1041692.019075] init: btsync main process ended, respawning
-
It would be really nice if btsync could utilize btrfs generations to quickly refresh its internal database upon startup.
Btrfs, being a copy-on-write filesystem, have built-in features to quickly list changes to the file system since a given point in time (generation)
Example:
root@skytown:/storage/media# btrfs subvolume show ./storage/mediaName: mediauuid: 6cde316a-1cad-4f41-a718-30a45292f9b6Parent uuid: -Creation time: 2014-05-04 07:15:24Object ID: 257Generation (Gen): 959Gen at creation: 6Parent: 5Top Level: 5Flags: -Snapshot(s):We're currently at generation 959, then i write to a file.root@skytown:/storage/media# echo foo > Music/Other/testAfter the transaction have committed (which it always does after 30 seconds, or due to sync() or umount, etc) we can query the filesystem for files that have changed since (a very fast operation compared to scanning the entire hierarchy) :root@skytown:/storage/media# btrfs subvolume find-new . 959inode 65807 file offset 0 len 4 disk start 0 offset 0 gen 1021 flags INLINE Music/Other/testtransid marker was 1021and we are now at generation 1021.I think it would be possible for btsync to utilize the btrfs generations to quickly refresh its internal state rather than having to scan the entire filesystem on startup.Please consider adding support for this, it would be super awesome. -
In OSX you have to use both SO_REUSEADDR and SO_REUSEPORT. BTSync sets these flags for SSDP listen socket. But if some other app doesn't use SO_REUSEPORT (since SO_REUSEADDR is enough in Linux), it will fail to bind to the same port.
I stand corrected. Thanks for the info!
-
It seems to me that BitTorrent Sync (1.1.15 on OS X) does not bind the SSDP (used for UPnP/DLNA) port using SO_REUSEADDR.
This prohibits other UPnP apps on the same host from receiving SSDP packets (ie, those apps does not function at all). Those other apps will fail to bind (Address already in use).
Most unix like systems allows multiple processes to bind the same UDP multicast port if all of them set SO_REUSEADDR before binding.
Also see: http://stackoverflow.com/questions/577885/uses-of-so-reuseaddr
Please fix this and I'll be an even more happy user of this awesome tool.
/andoma
[Solved] [V1.3.105] Higher Cpu Usage Than Older Versions On Linux/arm
in Sync Troubleshooting
Posted
Ok, it seems my problem was that a peer was running 1.2.92
I don't have any debug log left from when the problem occurred but I recall it complained about being disconnected when trying to transfer a file.