yottabit

Members
  • Content Count

    137
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by yottabit

  1. The FreeBSD x64 build of this version cannot write large files. I am trying to sync 50 GiB files. Reverting to 2.6.1 solved the problem for me. This can also be found as a solution for many experiencing the problem in FreeBSD jails, via the FreeNAS forums. Is there any plan to fix this? It's been 8 months...
  2. Ever since upgrading to 2.3.6 on FreeBSD 64-bit, after 1-2 days the syncs stop and I cannot login from the webui (keeps prompting for login over and over again with no errors). I have to kill the process, restart, and then back in business. Nothing in the log, even with debug enabled, to indicate there's a problem. Seen this yet? I've submitted a bug over the past weekend.
  3. @AlexanderD, thanks! Sorry but time got away from me before I was able to investigate further. Since upgrading to .128 it seems the .120 problem has been fixed. I still have two shares that had long-standing problems that I need to check.
  4. Seems to have fixed the syncing issue I had in .120. Thanks!
  5. I am having this "Will try to find peer for file ..." message in the debug log for many shares... nothing seems to be sync'ing now with this 2.0.120 version. I am using all Legacy 1.4 key-based sharing. Do you guys need any more logs? Do you have any test builds that may fix?
  6. I had sync'd 750 GB of files from my home NAS (FreeBSD) to a Linux VM on Google Cloud Platform (GCP), using EROS from NAS -> GCP. I was doing it to test a difficulty I had sync'ing to my friend's FreeBSD NAS with the same EROS where it would just stall at a high number of files remaining and never continue, no matter what we did (check UPnP rules on routers, create static port mappings, restart btsync, delete and re-add secret, etc.). Finally he deleted the EROS share and all data, and added it back at the same time I added the EROS to my GCP. Three-way sync started immediately and completed without issue. (Actually there were three files on my NAS that wouldn't sync until I ran "touch" on them, but that's not relevant to this issue.) Now that the sync is complete, I wanted to switch to ROS instead of EROS on my GCP. The data is already there as I had it sync'd before and didn't delete it while I was doing the EROS test. Unfortunately the GCP instance just sits there without transferring any files at all from my NAS or my friend's NAS. After a day it still says 55,024 files remain. Looking into the logs on both sides, it seems like my NAS instance is trying to connect to the private 10.x.x.x IP of the GCP rather than its ephemeral public IP. This is a static mapping done by Google's firewall rules and I haven't changed anything. Other services are continuing to work just fine. Any ideas what to try to get my and my friend's NASes to connect to the ephemeral public IP of GCP rather than the private 10.x.x.x IP of the VM host running the btsync instance? netstat on the GCP instance shows an established connection, yet in the logs I see attempted hits on that private IP. GCP: $ netstat -a | grep 4242tcp 0 0 *:4242 *:* LISTEN tcp 0 0 nas2-150127a.c.al:41967 pool-173-71-51-47.:4242 ESTABLISHEDudp 0 0 *:4242 *:*FreeNAS: # netstat -a | grep 4242tcp4 0 0 nas1.4242 250.51.154.104.b.41967 ESTABLISHEDtcp4 0 0 *.4242 *.* LISTENudp4 0 0 *.4242 *.*GCP log: $ grep 173.71.51.47 sync.log$ grep 172.16.42.25 sync.logFreeNAS log: # grep 10.240.140.165 sync.log [20150606 11:09:50.423] SD[EDC6]: Peer 2: local IP 10.240.140.165:4242# grep 104.154.51.250 sync.log[20150606 11:08:20.588] SF[EDC6] [12B9]: Going to send state notify to peer 104.154.51.250:41967 - root:D0B769EF3F6A6734970A3CC4412BD87E9490B7C8 pieces:4FB9897D0C1C0F182B46CBF77FF02911A1F4E8D6[20150606 11:09:50.423] SD[EDC6]: Peer 2: 104.154.51.250:4242 10E9410CB526E9C5364A6B921C622BC9C82512B9[20150606 11:10:00.443] SF[EDC6] [12B9]: Going to send state notify to peer 104.154.51.250:41967 - root:D0B769EF3F6A6734970A3CC4412BD87E9490B7C8 pieces:4FB9897D0C1C0F182B46CBF77FF02911A1F4E8D6[20150606 11:10:00.780] Incoming connection from 104.154.51.250:41967I'm perplexed.
  7. +1 Just tried to update 1.4 on my FreeBSD x64 box to 2.0 and can't hit the web gui no matter how I try. I'm open to running a test build to see if it fixes the problem. And I followed this topic so hopefully when I fix has been rolled out, Helen@ will ping this thread.
  8. Here's the log trail from the RO-enc 1.4 node: [20150218 21:25:36.447] SF[EDC6]: Torrent /mnt/jacob.mcdonald/NC7TZU6AGVVR7RM26AV2S2JER6BZ2RFLNWCDMSQ/FCT4GVBDOK3KFUB4KIJWHA6DVU/26JMPM2OYX4PB4U6YYUCAEFDY4S4PKMZJ7IPV4W7CABF2UVNNKH Q/7UHLBRBDX5MGH3ZVXUK4HISGYM/6PNX5UAIG6EJWCZMCNJAR44MW4 status:137 error:<NULL> meta:1 conns:0 io:0 [20150218 21:25:36.447] SF[EDC6]: Torrent /mnt/jacob.mcdonald/NC7TZU6AGVVR7RM26AV2S2JER6BZ2RFLNWCDMSQ/FCT4GVBDOK3KFUB4KIJWHA6DVU/26JMPM2OYX4PB4U6YYUCAEFDY4S4PKMZJ7IPV4W7CABF2UVNNKH Q/7UHLBRBDX5MGH3ZVXUK4HISGYM/5CLBYZL65W6BLYJ34RCDXKL32E status:137 error:<NULL> meta:1 conns:0 io:0 [20150218 21:25:36.447] SF[EDC6]: Torrent /mnt/jacob.mcdonald/NC7TZU6AGVVR7RM26AV2S2JER6BZ2RFLNWCDMSQ/FCT4GVBDOK3KFUB4KIJWHA6DVU/26JMPM2OYX4PB4U6YYUCAEFDY4S4PKMZJ7IPV4W7CABF2UVNNKH Q/7UHLBRBDX5MGH3ZVXUK4HISGYM/2FTAECKJNIIOUSZFDNWBVSOPUM status:137 error:<NULL> meta:1 conns:0 io:0 [20150218 21:25:37.450] SF[EDC6]: Max number of torrents reached (121) [20150218 21:25:37.450] ScheduledTask:ConnectMorePeers invoked:timer reason:UnloadInactiveTorrents - torrent wants connection [20150218 21:25:37.450] SF[EDC6]: Torrent /mnt/jacob.mcdonald/NC7TZU6AGVVR7RM26AV2S2JER6BZ2RFLNWCDMSQ/FCT4GVBDOK3KFUB4KIJWHA6DVU/27PW7EZNNOT2D2MUT3RGZRI5JA/2WATXBSL6NWSIPG4RWGFVQ2L LE/7JK6JU3L2GPXFGU7LHUK4WJ3RA/LHWR2DSGZNBULUN3252OTN6U2A status:137 error:<NULL> meta:1 conns:0 io:0 [20150218 21:25:37.450] SF[EDC6]: Torrent /mnt/jacob.mcdonald/NC7TZU6AGVVR7RM26AV2S2JER6BZ2RFLNWCDMSQ/FCT4GVBDOK3KFUB4KIJWHA6DVU/27PW7EZNNOT2D2MUT3RGZRI5JA/2WATXBSL6NWSIPG4RWGFVQ2L LE/7JK6JU3L2GPXFGU7LHUK4WJ3RA/IQ7M76ATAH6NQPOBYKGOFUQYCI status:137 error:<NULL> meta:1 conns:0 io:0 [20150218 21:25:37.450] SF[EDC6]: Torrent /mnt/jacob.mcdonald/NC7TZU6AGVVR7RM26AV2S2JER6BZ2RFLNWCDMSQ/FCT4GVBDOK3KFUB4KIJWHA6DVU/27PW7EZNNOT2D2MUT3RGZRI5JA/2WATXBSL6NWSIPG4RWGFVQ2L LE/7JK6JU3L2GPXFGU7LHUK4WJ3RA/IEQS63SL6GE5YGTJERT57ERMYU status:137 error:<NULL> meta:1 conns:0 io:0
  9. EDIT: edited for clarity Hi Helen, This is a one-way sync to two other nodes (1x RO & 1x RO-encrypted). All nodes were originally 1.4. The source node remains 1.4. The RO node was upgraded to 2.0. The RO-enc share remains at 1.4. The source 1.4 node reports that 82 GB (26,398 files) of the 722 GB total still needs transferred to the RO 1.4 node. The RO-enc node is not finishing the sync, either. The source 1.4 node reports it needs to send 133 GB to the RO-enc node, and the RO 2.0 node reports it needs to send 63 GB to that same RO-enc node. Source 1.4 node log tail: [root@nas1] /mnt/vol0/btsync# tail -n 50 sync.log[20150218 09:04:57.558] DEBUG: Connect more peers, number of torrents: 0[20150218 09:04:57.563] DEBUG: Connect files for peer 130.211.119.218:4242[20150218 09:04:57.563] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:04:59.090] DEBUG: Connect more peers, number of torrents: 2[20150218 09:04:59.094] DEBUG: Connect files for peer 130.211.119.218:4242[20150218 09:04:59.095] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:04:59.095] DEBUG: Connect more peers, number of torrents: 2[20150218 09:04:59.107] DEBUG: Connect files for peer 130.211.119.218:60292[20150218 09:04:59.107] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:04:59.107] DEBUG: Connect files for peer 174.103.152.249:18662[20150218 09:05:00.026] DEBUG: Connect more peers, number of torrents: 6[20150218 09:05:00.039] DEBUG: Connect files for peer 130.211.119.218:60292[20150218 09:05:00.039] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:05:00.039] DEBUG: Connect files for peer 174.103.152.249:18662[20150218 09:05:01.075] DEBUG: Connect more peers, number of torrents: 7[20150218 09:05:01.079] DEBUG: Connect files for peer 130.211.119.218:4242[20150218 09:05:01.079] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:05:01.079] DEBUG: Connect more peers, number of torrents: 7[20150218 09:05:01.093] DEBUG: Connect files for peer 130.211.119.218:60292[20150218 09:05:01.093] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:05:01.093] DEBUG: Connect files for peer 174.103.152.249:18662[20150218 09:05:02.238] DEBUG: Connect more peers, number of torrents: 2[20150218 09:05:02.243] DEBUG: Connect files for peer 130.211.119.218:4242[20150218 09:05:02.243] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:05:02.243] DEBUG: Connect more peers, number of torrents: 2[20150218 09:05:02.256] DEBUG: Connect files for peer 130.211.119.218:60292[20150218 09:05:02.256] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:05:02.256] DEBUG: Connect files for peer 174.103.152.249:18662[20150218 09:05:03.261] DEBUG: Connect more peers, number of torrents: 0[20150218 09:05:03.266] DEBUG: Connect files for peer 130.211.119.218:4242[20150218 09:05:03.266] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:05:03.266] DEBUG: Connect more peers, number of torrents: 0[20150218 09:05:03.279] DEBUG: Connect files for peer 130.211.119.218:60292[20150218 09:05:03.279] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:05:03.279] DEBUG: Connect files for peer 174.103.152.249:18662[20150218 09:05:07.661] DEBUG: Connect more peers, number of torrents: 0[20150218 09:05:07.665] DEBUG: Connect files for peer 130.211.119.218:4242[20150218 09:05:07.666] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:05:09.686] DEBUG: Connect more peers, number of torrents: 0[20150218 09:05:09.699] DEBUG: Connect files for peer 130.211.119.218:60292[20150218 09:05:09.699] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:05:09.699] DEBUG: Connect files for peer 174.103.152.249:18662[20150218 09:07:46.463] DEBUG: Connect more peers, number of torrents: 0[20150218 09:07:46.476] DEBUG: Connect files for peer 130.211.119.218:60292[20150218 09:07:46.476] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:07:46.476] DEBUG: Connect files for peer 174.103.152.249:18662[20150218 09:07:56.028] DEBUG: Connect more peers, number of torrents: 0[20150218 09:07:56.041] DEBUG: Connect files for peer 130.211.119.218:60292[20150218 09:07:56.041] DEBUG: Connect files for peer 0.0.0.0:0[20150218 09:07:56.041] DEBUG: Connect files for peer 174.103.152.249:18662RO 2.0 node log tail: root@nas2-150127a:/mnt/btsync/.sync# tail -n 50 sync.log[20150218 15:09:17.518] Incoming connection from 174.103.152.249:10509[20150218 15:09:23.023] MC[7A4B] [82B2]: failed to verify signature of remote file 00-Pictures/07 JUN 08, aborting[20150218 15:09:27.344] Incoming connection from 174.103.152.249:10509[20150218 15:09:28.391] TorrentFile: unloading torrent by timeout[20150218 15:09:28.391] TorrentFile: unloading torrent by timeout[20150218 15:09:28.391] TorrentFile: unloading torrent by timeout[20150218 15:09:28.391] TorrentFile: unloading torrent by timeout[20150218 15:09:28.391] TorrentFile: unloading torrent by timeout[20150218 15:09:29.443] TorrentFile: unloading torrent by timeout[20150218 15:09:29.443] TorrentFile: unloading torrent by timeout[20150218 15:09:29.443] TorrentFile: unloading torrent by timeout[20150218 15:09:30.036] TorrentFile: unloading torrent by timeout[20150218 15:09:30.036] TorrentFile: unloading torrent by timeout[20150218 15:09:31.600] MC[7A4B] [82B2]: failed to verify signature of remote file 00-Pictures/07 JUN 08, aborting[20150218 15:09:33.228] TorrentFile: unloading torrent by timeout[20150218 15:09:33.228] TorrentFile: unloading torrent by timeout[20150218 15:09:33.228] TorrentFile: unloading torrent by timeout[20150218 15:09:33.228] TorrentFile: unloading torrent by timeout[20150218 15:09:34.415] TorrentFile: unloading torrent by timeout[20150218 15:09:34.415] TorrentFile: unloading torrent by timeout[20150218 15:09:34.415] TorrentFile: unloading torrent by timeout[20150218 15:09:34.415] TorrentFile: unloading torrent by timeout[20150218 15:09:35.045] TorrentFile: unloading torrent by timeout[20150218 15:09:35.045] TorrentFile: unloading torrent by timeout[20150218 15:09:35.045] TorrentFile: unloading torrent by timeout[20150218 15:09:35.045] TorrentFile: unloading torrent by timeout[20150218 15:09:36.046] TorrentFile: unloading torrent by timeout[20150218 15:09:36.046] TorrentFile: unloading torrent by timeout[20150218 15:09:36.046] TorrentFile: unloading torrent by timeout[20150218 15:09:37.118] TorrentFile: unloading torrent by timeout[20150218 15:09:37.118] TorrentFile: unloading torrent by timeout[20150218 15:09:37.118] TorrentFile: unloading torrent by timeout[20150218 15:09:37.118] TorrentFile: unloading torrent by timeout[20150218 15:09:37.118] TorrentFile: unloading torrent by timeout[20150218 15:09:37.118] TorrentFile: unloading torrent by timeout[20150218 15:09:37.118] TorrentFile: unloading torrent by timeout[20150218 15:09:37.118] TorrentFile: unloading torrent by timeout[20150218 15:09:37.128] Incoming connection from 174.103.152.249:10509[20150218 15:09:38.080] TorrentFile: unloading torrent by timeout[20150218 15:09:38.080] TorrentFile: unloading torrent by timeout[20150218 15:09:38.080] TorrentFile: unloading torrent by timeout[20150218 15:09:38.080] TorrentFile: unloading torrent by timeout[20150218 15:09:38.080] TorrentFile: unloading torrent by timeout[20150218 15:09:38.080] TorrentFile: unloading torrent by timeout[20150218 15:09:38.080] TorrentFile: unloading torrent by timeout[20150218 15:09:39.465] TorrentFile: unloading torrent by timeout[20150218 15:09:39.466] TorrentFile: unloading torrent by timeout[20150218 15:09:39.466] TorrentFile: unloading torrent by timeout[20150218 15:09:39.466] TorrentFile: unloading torrent by timeout[20150218 15:09:39.466] TorrentFile: unloading torrent by timeoutI don't have direct access to the RO-enc 1.4 node; I'm waiting on that admin to give me a log tail. I have tried restarting all btsync processes, too, but it doesn't help.
  10. I am having this same problem trying to interop a share between 1.4 and 2.0.
  11. Offline peers will remain in the peers list for some period of time. If the peer doesn't come online again within the period of time, it will be removed from the list. I believe the period of time is one or two weeks.
  12. Thanks, RomanZ! I didn't see a PM from you for the Linux build, though. I'll take it, as well as wait for the FreeBSD build when it's ready. Thanks again!
  13. RomanZ, I've been experiencing Out of Sync on at least 7 of my 11 shares on FreeBSD x64, and 7 of my 9 shares on Linux x64. What is the risk in the experimental build? I haven't asked yet because I would have expected it to be released here on the forums for general use, rather than one-off e-mails/PMs, if it was fit for general use. If the risk is negligible, why not post it to the forums like typical? If you guys don't want to do that yet, please do send me a link for the x64 versions of FreeBSD and Linux, if you consider them stable. Thanks!
  14. Have you tried enabling TCP, and disabling encryption, for the LAN connection? Made a huge difference for me. Theoretically UDP should of course be faster than TCP on a LAN, but I've come to find out that UDP segment processing is usually not offloaded/accelerated while TCP is... One other thing I've seen cause a slow down is poor hard drive performance (old drives, show SATA, fragmentation, etc.). I don't get anywhere near full speed on gigabit LAN unless I'm using SSD. Not saying it's for sure the problem, because there are lots of variables involved, but just one more thing to check.
  15. Also there's an option to use TCP on LAN instead of UDP, which *could* be faster depending on your network interface capabilities. Parts of TCP are often offloaded (accelerated) to an ASIC on the network PHY and UDP usually isn't.
  16. Confirmed fixed in 1.1.70 build for BSD, too.
  17. Sounds like implementing pMTU Discovery may be needed then. I agree it may be needed, usually on sat links and PPPoA DSL (PPPoE is probably more flexible). Should be easy enough to implement but would require a protocol bump, unless it's handled independently by the clients before the transfer protocol takes over.
  18. Fragmentation for TCP is handled at the TCP level in the operating system, not by the application level. However, BTSync uses UDP and I have no idea how UDP fragmentation works. UDP is typically used for small packets (think VoIP or sometimes video streams) so fragmentation is not an issue. However, when used for file transfers, I would expect large packets. There are some utilities that will allow you to perform UDP-based pings where you can manipulate the packet size. You might want to try something like that to see if your operating system will automatically fragment UDP packets (I don't even know if this is possible or how it works; I would have to read up on UDP specifics but I don't have time at present).
  19. Will 1.1.15 auto-update to 1.1.22 eventually? Or will this always be a manual upgrade?
  20. Junctions seem to be more compatible and better supported.
  21. In a debug log I'm getting this repeatedly: [2013-05-29 22:48:15] Torrent 1532952576-11280600.jpeg status: 137 error: <NULL> meta: 1 [2013-05-29 22:48:15] Torrent 1521647616-10463714.jpeg status: 137 error: <NULL> meta: 1 [2013-05-29 22:48:15] Torrent 151289856-7304695.jpeg status: 137 error: <NULL> meta: 1 I can't get the files to transfer. The GUI shows the other computer directly connected. The debug log also shows the other system responding to ping requests. It seems like it should work ... Any ideas?
  22. Sorry kos, my FreeBSD install still doesn't see the update today, 28 May ...
  23. No, no. I realize build 134 isn't "new" -- what I'm saying is that the "auto update" feature looks like it has finally been officially turned on, so the clients will update themselves, without requiring download & reinstall. However, I notice this only appears to be the case with my Windows clients. My Linux and FreeBSD clients still say they're "up to date," i.e., the auto-update feature hasn't registered with them yet. I didn't see any reference to the auto-update feature being turned on in any recent posts. And I did a quick search to be sure.
  24. My Windows clients running 1.0.116 and 1.0.131 just now showed an auto-update message to 1.0.134. Linux on 1.0.116 and FreeBSD on 1.0.130 still report "up to date" ... Any ideas when we will see auto-update function for Linux & FreeBSD? Thanks!!
  25. I'm running the p2 patch of the same NAS and have no problems. Btsync is RAM and disk intensive. Are you sure there's no faulty hardware lurking?