Comment Re:Performance? (Score 1) 212
I don't know. I don't have that many users.
I can tell you that one of the filesystems I archive has lots of small-ish files in it. Like over 300,000 files averaging like 250kb each. The rsync takes a few seconds to scan everything. Lots of changes or changes to big files will slow things down during the copy.
Oh, a handy tip for running big Linux fileservers: have a minimum of 1 GB RAM per 1 TB of storage. No matter what you are doing with your server, you want lots of room for the stat cache. Even more if you are scanning regularly looking for changes.
As long as the system functions well as a file server, the versioning backend shouldn't hurt too much. A slow sync shouldn't interfere with normal usage, it just reduces the maximum scan frequency.
One small disadvantage to this system is that it has a window. Things can happen in that window that will never be seen. If you have one of the very rare cases where you absolutely need to catch every single change, you can't use this; you need to use COW.
For everyone else, this is a very good solution. And it is fun to set up. One more tip, think about your locks in advance, and pay attention to situations where it makes more sense to bail out entirely (and wait for the next pass) rather than waiting for the lock to clear.