(Illustration by Gaich Muramatsu)
On Fri, Jul 25, 2008 at 02:41:43PM -0700, Andy Valencia wrote: > FYI, for FreeBSD 7.0 I found that the latest Coda stuff was in the ports > tree, but this didn't include the kernel module. All I could find on > the kernel side was back an entire revision. I was in an environment > which already had Coda running, so I didn't want to drop back a rev. I just checked and the Coda kernel module in FreeBSD 7.0 is correct and current. There is a COMPAT_CODA_5 define to revert back to the older interface, but if that is not defined it uses the current kernel-venus api. > I queried here, and didn't get a response. So I'm assuming that > tracking FreeBSD is not much of a priority. I missed the mail, but even then it took me a while to figure out which release FreeBSD 7.0 was the most current stable release, Coda support was broken in the previous stable. > So proceed with caution. As far as I can tell, Coda doesn't scale to > modern media sizes. Depends on what you want to store. Coda doesn't scale well to millions of files, but if the files are of moderate length (several megabytes each, f.i. single track music files or digital photos) it has no problem filling up a few hundred GB of disk space. > And you will want a non-Coda backup system which is > run often enough to stay very current. I've been running Amanda myself, and just this week set up BackupPC, which uses content hashes to avoid storing duplicates of the same data. This is really nice when you backup up all available replicas of replicated volumes because you only end up storing one copy as long as the replicas are in sync. Of course it also revealed an issue where a volume dump gets aborted when the socket buffers fill up and the volutil process blocks while trying to write more. > Sorry to sound so negative, but my experiences really didn't lead me to > believe that Coda is ready for a production environment. That's ok. I happen to use Coda for our web server, my email, and various other people have found uses as well. But there are still situations where it may not be as reliable. Partly this is because Coda uses optimistic replication, and when that optimism fails it falls back on heuristics to fix up any resulting conflicts. Those heuristics are not all encompassing, directory resolution has gotten reasonably usable. But there are still corner cases, one I know of and am working on is when a file is created on one replica, we then store the data and try to resolve the store operation. Because the other replica(s) have not yet seen the create they don't recognise the file and we get a conflict. Most of the time it works, because the parent directory (create operation) is resolved first, but once in a while things happen in the wrong order and we get a conflict. So hopefully at some point we will be able to handle whatever problems are triggered by your usage models as well. JanReceived on 2008-07-26 02:04:46