krtaylor
-
Posts
41 -
Joined
-
Last visited
-
Days Won
1
Posts posted by krtaylor
-
-
I am using BTS for what amounts to a family backup network. We each have a large music collection, large collection of digital photos, and other miscellanous files wanting to be backed up. By establishing BTS folder shares, everyone's files are automatically backed up to each of the other nodes so a fire can't destroy all someone's data. We all already pay for broadband connections, generally leave our computers on 24/7, and hard drive space is cheap.
The trouble is, I am noticing that BTS proc and memory requirements seem to scale to the point where it's not actually capable of ever finishing indexing, especially now with each new version requiring a fresh indexing from scratch.
Currently we have 12 shared folders ranging from 5MB up to 150GB and 3 files up to 30,000. The total data synced is around 370GB.
Oh, and, most (not all) of the shares are read-only at all nodes other than their source. I still encounter the old bug of the last couple files not ever showing as synced, but rarely.
But the two newest shares always just show 0 for files and size (not true) as that node is relatively old and slow and never finishes indexing everything higher in the list. So we appear to have reached a practical limit of some kind.
a) Does anyone else out there deal in volumes like this, either in number of folders, number of files, or data volume?
Is anyone else running into this kind of limit? I assume there hasn't been formal testing of limits nor anything hard-coded? -
I certainly understand that a given instance of BTS is going to behave oddly if its local hard disk is full. That's just common sense.
My complaint is that a full hard drive on one node causes BTS on a completely different node to ALSO behave oddly, involving shares with third nodes that also don't have any immediate hard drive problems. That's what I'm not sure was covered in the "known issues."
-
I have a very large and somewhat complex BTS network, with up to 8 computers involved in various separate locations and a dozen separate sync folders, with up to 100GB and 10000 files. Some are read-only on certain nodes, not all nodes have all folders, etc. All are on broadband connections but some of the systems are a bit old and slow.
Anyway, on one of the systems, one of the hard drives used for one of the shared folders filled up. Obviously that node stopped taking in any more files.
However, as far as I can tell, my **entire BTS network** locked up. Everything stopped indexing and all update traffic stopped, even between other systems with plenty of room on their hard drives.
As soon as I discovered the problem and moved things around to make room on the full drive, everything across the network started working again. But this seems like a pretty serious weakness, especially considering the direct cause: the new versioning file copies found in .SyncTrash. For some reason almost everything was copied in there, taking up twice as much space and filling up the drives way beyond what we expected. I had to go around and empty them all.
1. BTS needs to be able to work around one node that has problems, and let other nodes continue to update.
2. There needs to be the option to turn off versioning, or better yet, to use the Recycle Bin (on Windows) instead of the special .SyncTrash folder. That way older files in the Bin can be automatically eliminated when the hard drive fills up.
I am using the newest version, 1.1.22, on all nodes.
-
I have a similar problem I thought was restricted to read-only shares, but now I'm not sure - I have monster shares of many GB so it takes a long long time to fully index and then sync. Can you clarify what you said above, "When BTSync is restarted, the sync restarts perfectly." Do you mean, you simply quit the program at the node with the trouble, then started it up again and it behaved correctly? Or did you mean you had to re-initialize the entire sync at both ends?
-
I upgraded all my nodes to 1.1.115, and now this problem is back - Read-Only syncs never quite think they are finished with the sync. Is this on the buglist still I hope?
-
Now that's something that I didn't think of. I've been sending my logs to support, and they had me try out version 134, which appeared to make the problem go away - as in, both ends show as being synced.
However, I remember back when I was using Windows Live Mesh, I had to run it as admin, because otherwise it would get hung up on some files being the wrong owner or read-only. I haven't **noticed** this problem with BTS, but perhaps that was the underlying cause of the not-quite-finished-syncing problem? If so, perhaps the "fix" for this problem was BTS simlpy disregarding files that it's not allowed to write over - which if true, isn't really a "fix" so much as a workaround?
Is it possible to run BTS as admin so as to prevent this potential problem? I have BTS set to automatically run on startup so I don't have control of which account it is running under - I do NOT log in with admin privileges, so that suggests that BTS doesn't have them either.D
Does anybody know more about exactly how this works?
-
Good idea! I've done that.
-
I tried to email in my logfile but it was too large - 32MB. Is there some place on the forum I can upload it to?
-
I am 99% certain that all files are really the same, because previously they were synced with Cubby which doesn't have a read-only mode. I turned off Cubby and turned on BTS without making any changes in between.
I ran another test on a different folder with three computers, all of which were also previously synced together with Cubby. Two of the computers have full access shares in BTS, and they correctly display as being synced. The third folder has read-only access, and it too has a few MB showing as remaining from the sending end, while showing as fully synced at the read-only end.
-
OK, I did as instructed.
At first it worked fine - both ends scanned, then it started working down from the total as the files were checked and found to be the same.
But at the very end it got stuck. The read-only side accurately says "Synced" whereas the read-write end is stuck on the last 6.4MB.
-
I've not used the BTSync WebUI, is that functionally different from the Windows UI?
-
I updated, and actually the problem got worse. Previously I had one share that was full privileges which correctly said that it was fully synced, and one that was read-only at the other end which was having the problem described.
I updated this end, and now both of those shares show the up-arrow and total size, but aren't actually doing anything (because really they don't need to).
So I went and update the other end, and I'm back where I started: the full-rights share displays correctly, the read-only one wrongly says it needs to transmit everything but doesn't. So I'm afraid this particular bugfix didn't fix this particular bug.
-
Is there a delay before it appears on the auto-update server? I just hit the "Check Now" button and it says I'm up-to-date, but I'm running 1.0.116.
-
BTS is a great product and I'm very happy with it, having moved off of Cubby when they decided to rip us off, and before that from Live Mesh which worked well for years for us. :-(
It's very close to perfect for our needs, in some ways better than either Cubby or Mesh. There are a few Wishlist suggestions that would still be very helpful:
+1 for "mirror" type read-only sync
+1 for "update scan" button on read-only sync - basically like the mirror, but manual. Both these seem to be pretty popular and useful suggestions, is there any way of knowing if they are on the official dev list?
+1 for showing all currently authorized syncs on the Devices list, even when that particular device is not connected. This allows you to easily monitor the status of remote locations - "oh, something's wrong, that one's not tying in, I'd better go look at it." Yes I know there are plenty of remote monitoring programs, but esp since BTS is not a Windows Service, a remote location can be perfectly healthy and yet BTS isn't running.+1 for making it a Windows service so you don't have to be logged in to run it.
It would also be very useful to allow a device to be kicked out of the sync from the Devices list. Mesh used to allow this and it was much easier than having to turn off a sync at each node individually. Of course that would not delete the files already synced and that's fine.
If there's a new Wishlist suggestion I have, it would be more "eye-candy"-like status information. For instance, one of the earlier Cubby versions had an extremely helpful popup that showed the currently active connections between your node and remote nodes that were sending/receiving data. I know that similar information can be had in the Transfers and History tabs, so this isn't essential, but graphic status is nice. Maybe an easier way to accomplish something similar would be to have animated icons on the Devices tab instead of the static ones currently used, showing visually which shares are actively transmitting and which aren't. Oh, and those icons should have popup rollover text stating what they mean, it's not always totally obvious.
Overall, a great program, and I'm looking forward to future developments! -
I have the exact same problem the OP has described.
Is anyone else running into this kind of limit? I assume there hasn't been formal testing of limits nor anything hard-coded?
Practical limits to BTS size/number?
in Sync General Discussion
Posted
I am using 1.1.26. All systems involved have a minimum of 2GB of memory and running Windows 7.
The oldest system is running about 75% memory usage but the procs are flat out - 100%. I'm not totally sure it's the fault of BTS but nothing else is running other than normal system services.
I'm noticing a new problem though. My nodes have mostly completed syncing, but they are now stuck on an endless loop that appears in the Transfer window. They each show the same 3 files transferring but with 0 for both upload and download. The window does change, as sometimes it says there are no transfers, other times 1, 2, or 3 of the files in question. There is other data that needs to be transferred but it never gets a chance. Unfortunately, it does not display the path of the files in question so I don't know exactly what they are.
I'll send in a log file shortly.