syncany-team team mailing list archive

[João Almeida <jpoalmeida@xxxxxxxxx>]

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 <spam@xxxxxxxx> 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
> spam@xxxxxxxx
>
> --
> Mailing list: https://launchpad.net/~syncany-team
> Post to     : syncany-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~syncany-team
> More help   : https://help.launchpad.net/ListHelp
>