Comparision to rclone
ad-m opened this issue · comments
How do you compare juicesync to rclone sync ( https://rclone.org/commands/rclone_sync/ )? What are the advantages? What are the expected benefits? What caused the creation of a new project, instead of developing the existing ones?
Rclone is a great tool and can do many things. juicesync is close to rclone sync with some difference:
- juicesync supports HDFS, UFile, Qiniu.
- juicesync use multiple machines to copy files in parallel.
- juicesync has simper interface, does not require a config file to work with.
Most of the code in juicesync came from JuiceFS [1], which is a file system we build in house. We don't intend to compete with Rclone, just give people another choice.
juicesync is expected to be a simple tool to move data around as fast as possible. it's still young, stay tuned.
This is a good question, thanks for asking.
Thanks for the clarification.
The intention of my question was to get an understanding of when which tool to use in order to use a good tool for a good job. This is my first time seeing juicesync and it is not trivial to spot the differences. I completely missed that juicesync can run in distributed mode.
There is outgoing for support HDFS (rclone/rclone#4640). There was no community interest for UCloud UFile (https://github.com/rclone/rclone/search?q=UCloud&type=issues). Qiniu have S3-compatible gateway ( rclone/rclone#3189 ), so it's supported by rclone already. I think adding an additional back-end to rclone is not a big deal.
The way of passing the parameters is just a matter of the user interface, the development of which is minimal compared to all other elements. I have a feeling this can be changed by using rclone as a library.
Distributed sync is functionality that is actually hard to recreate in rclone propably. This is the real advantage of juicesync that makes the tool unique. Thank you for pointing this out.