Scorp1us
-
Posts
12 -
Joined
-
Last visited
Posts posted by Scorp1us
-
-
BTSync does that. However this is not how rsync works. If you will add just one byte, all chunks will be changed. You need to detect shifted chunks.
Can you elaborate on what Sync is capable of detecting and how it responds?
-
The problem I have with labeling this thing as a good thing for the "cloud" is cloud files are not the same as general torrents. Torrented files are copies of an original that never changes. With cloud files,, there is a higher expectation that this is a working file.
-
That's not a fair comparison. If someone wrote Sync with all the features it has, which uses BT, then a fair comparison is if someone wrote a comparable Sync for RSync. BT and RSync are the protocols, Sync is a app using the protocols.
-
Well then that's cool!
-
Why bicker about it? rsync is still there as it always has been. Use the appropriate tool for the task at hand.
Very much so. But I suggest you take it further. Use the appropriate protocol for the task at hand. If BT would be inferior, switch to Rsync. Then you have one tool that can work better in more situations. But the important distinction is that the computer knows, so the computer picks. The choice can be hidden from the user and they just see lots of win.
-
Yes, this was a surprise to us too, that Sync is the only effective way to send 1Gb between 3 computers.
This is an interesting claim. No matter what protocol, you have to send 2gb to have the same file on all computers.But I am interested in what happens next. If you modify the file, what has to be transmitted? Perhaps it is just publish/download. But once distro I used only provided Rsync of ISOs so you'd only get the 20mb or so of changes. How does bittorrent respond?
To me one of the advantages of Bittorrent is when you have lots of seeders. But if you have a microcloud of 3, I don't see BT doing nearly as well.
-
Forgot your original question
I am not aware of any rsync based solution that is serverless and distributed. Sync is truly server-less and distributed, this is why it is not rsync based.It depends on how you define "server" RSync can operate on it's own by comparing two files. If one of the files is remote, it is heavily benefited by being able to calculate the checksums locally, then comparing them. So yes, there may be a "server" on the remote system that reads the file and transfers the checksums. Then once that is done, the server accepts and applies the incoming deltas.
-
As an aside, I just find it amusing that it is 2013, 50 years after the first filesystems and 20 years since the took off web we're still inventing ways to move files between computers.
-
But RSync is only available for Unix based systems!
False. There are no algorithms that can't be done on Windows if they are done on Unix https://www.itefix.no/i2/cwrsync (Python: http://blog.liw.fi/posts/rsync-in-python/ )
it would me interesting to see if you could replace your torrent based solution with rsync and see which one comes out ahead.
-
True, but it would be interesting to see in some tests who performs better.
Given that most changes are small incremental ones, rsycn should be competitive for a large number of test cases.
I thing you'd need an organization to generate enough load that rsync starts to falter. Which is fine, but when I hear "dropbox" I think individual.
-
So RSync is good at transferring files, and the differences between them. Meaning added, deleted or changed blocks. And given that you create/modify at one location at a time. Rsync seems a better fit.
Bittorent is engineered for getting 1 file from many sources. You're not going to have many sources in your private cloud.
So why should we use bit torrent. I can't think of any reasons to, but many not to:
- ISP throttling/blocking.
- RSync is more efficient.
I am not aware of any rsync based solution that is serverless and distributed. Sync is truly server-less and distributed, this is why it is not rsync based.
Why not just use RSync?
in Sync General Discussion
Posted
If we're talking about beat practices, you shouldn't be using sync to manage a web server. What you should be doing is having a development code base, in a version control system (assume git) you have release and testing branches, and your production server just pulls the release branch. The fact that you can check in any tweaks (usually config mgt) from the production webserver and inegrate them into the dev branch is a very valuable back-flow.