Comment 7 for bug 889084

Now now there, ZFS is on its own league :D And setting up a nice array is
an art ;)

Plus, I don't think Syncany can ensure data integrity all the way like ZFS
does.

On Mon, Feb 20, 2012 at 10:03 AM, Spam <email address hidden> wrote:

> Syncany is a beast. Syncany is not just Dropbox or SparkleShare.
> Syncany actually does encryption of the data, they built the
> infrastructure for block chunking with deduplication, they have
> multiple backends. This is a feature full program; that isn't a
> simple thing. If you use ZFS with deduplication you need many
> gigabytes of memory and it's not doing encryption. Add the
> compression and you get even worse memory usage. People who have
> storage arrays of a few terabytes have systems with 16GB of RAM and
> the ARC Cache alone takes up 6 GB or so during normal usage. This is
> a fully featured program. ZFS in software almost. It's not something
> simple like Dropbox.
>
> If you can come up with a closer analog than ZFS that uses much less
> RAM and has better startup times, I would love to see it. I've been
> looking for a while and still haven't found an optimal storage
> platform. If my Android phone, a memory limited device, can handle
> many complicated tasks and run fairly quickly, I don't think it's Java
> that's the problem. It's a combination of memory hungry, processor
> intensive features and bugs that need fixing.
>
> This is opensource. If you have such a strong opinion on what
> language should be used for this project, you are free to take it and
> port it. You have that freedom. With opensource, you are never in a
> position where you can demand or complain. Come with data, like a
> profile that shows where the code spends a lot of time or wastes a lot
> of memory. Come with a patch. We all want this to be better. One of
> the points of opensource is acknowledging that we aren't smart enough
> ourselves and we need help with this.
>
> Finally, when the new code is pushed, there will be better
> opportunities to target specific parts. If you want a daemon written
> in C or Python, it will be easier. This architecture issue is on the
> TODO and will make it much easier to tackle this type of problem.
> This way it will be easier to think of Syncany less as a specific
> program, like AIM, but more like a protocol, like XMPP. When a
> Syncany client is written for iOS, it will be written in Objective-C,
> when it's written for Android, it will be in Java, when it's the
> backend, there may be a couple of different backend implementations
> with different advantages. We will, hopefully soon, have that
> freedom.
>
> R. Mason
> <email address hidden>
>
> --
> Mailing list: https://launchpad.net/~syncany-team
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~syncany-team
> More help : https://help.launchpad.net/ListHelp
>