2bluesc

I observed a large number of packets from BitTorrent Sync's LAN discovery hitting my Linux firewall: [31888.915645] [UFW BLOCK] IN=eth0 OUT= MAC= SRC=1.2.3.4 DST=239.192.0.0 LEN=126 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=3838 DPT=3838 LEN=106 Running tcpdump at the same time displays the outgoing packets (and the firewall catches and blocks the return) When I shut off "LAN Search" for all my shares, it instantly stops. The problem with this is that my workstation running btsync is also my NAT router and WiFi AP, it has 3 interfaces: eth0 connected to the Internet eth1 connected to my LAN wlan0 wireless LAN, note this is on it's own subnet, not bridged with eth1 If I add the following route, the broadcasts immediately start getting sent out on eth1 where my LAN actually is: ip route add 239.192.0.0/14 dev eth1 Is there anyway to configure this within BitTorrent Sync, for example select a LAN interface so I don't broadcast multicast stuff to all my cable modem neighbors and so that I actually discover devices on my LAN? This also prevented LAN discovery from working. I imagine this could be a problem for laptops with Ethernet + WiFi, but they likely aren't both enabled at the same time.

I think we're looking at different things. I'm comparing how much disk space is actually used by the metacache (266 MB) with the actual data stored in the files (6.41 MB). This is the overhead of my filesystem (ext4 on Linux) inefficiently storing 66142 files. My actual file data that is synced is 11GB and I'm running version 1.0.134.

When my backups ran the night after I started playing with BitTorrent Sync I was shocked to see how large the metacache folder was. The actual disk usage for my metacache directory is: $ du -hs metacache/ 266M metacache/ A closer look reveals a ton of small files, most of which are smaller then my block size on ext4 (dumpe2fs reports "Block size: 4096"). This means a ton of space is likely wasted. I wrote a quick awk script to understand the metacache directory (https://gist.github....lemanna/5653926) $ ./real-size.sh metacache | tail -n23 47 occurrences of file size = 199 48 occurrences of file size = 480 56 occurrences of file size = 360 67 occurrences of file size = 380 77 occurrences of file size = 340 91 occurrences of file size = 320 107 occurrences of file size = 300 116 occurrences of file size = 280 156 occurrences of file size = 260 172 occurrences of file size = 240 242 occurrences of file size = 220 286 occurrences of file size = 200 469 occurrences of file size = 179 644 occurrences of file size = 159 993 occurrences of file size = 138 1917 occurrences of file size = 118 2598 occurrences of file size = 75 5211 occurrences of file size = 98 5222 occurrences of file size = 78 12804 occurrences of file size = 76 Total filesize: 6717161 Total filecount: 66142 Total files with size < 4096: 32436 -> 49.0399% Out of 266 MB for the entire metacache directory, only 6.41MB (6717161 bytes) is actually storing usable data. About 49% of the files are under the 4096 block size. If we add in the disk space wasted including directories it grows even more: $ du -bs metacache 14605231 metacache That's 13.93MB (14605231 bytes) for directory data and file data, all to store 6.41MB of real data. Space wasted (1 - 6.41/266 ) is 97.59% I can only imagine how this will scale as more and more files get added. Are there plans to use a database (sqlite?) of some sort to improve disk utilization as well probably improve performance? I saw mention of a solution a month ago. Any updates on this? Other then this, Bittorrent Sync is a very interesting tool. I look forward to it improving. I wish it was open source though...