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 protected]> 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 protected] > > -- > Mailing list: https://launchpad.net/~syncany-team > Post to : [email protected] > Unsubscribe : https://launchpad.net/~syncany-team > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~syncany-team Post to : [email protected] Unsubscribe : https://launchpad.net/~syncany-team More help : https://help.launchpad.net/ListHelp
