(Illustration by Gaich Muramatsu)
Hauke Fath <hf_at_spg.tu-darmstadt.de> writes: > On Tue, 27 Jan 2015 16:11:38 -0500, Greg Troxel wrote: >> Also, there are solaris patches just arrived in pkgsrc. I am unclear on >> whether that means someone has the kernel code working, > > I am looking at how my group could use Coda to be less dependent on a > working network. Since the fileserver runs OI, I made Coda build there, > and only after the commit I realised there was an important bit missing > (<http://marc.info/?l=linux-coda&m=124181000316589&w=2> is the latest > news I could find). To really be able to use coda, it has to be both reliable and portable. Right now both are issues. For portability, the problem is that it only runs on NetBSD and Linux, as far as I know. For reliability, it mostly works, but it's too easy to get venus hung up. On upgrading from NetBSD 5 to 6, I found two bugs. One was a regression in mmap/munmap of coda files in the kernel interface due to some new assert. I worked around that by disabling mmap. The other is that removing a directory leads to venus spinning, and I haven't investigated. I can see two ways forward: Make a FUSE interface for venus, so that it will run just about everywhere.* Create a new (FUSE-based) filesystem that is much like the current system, but can do write-disconnected caching based on some other filesystem that doesn't handle disconnects (sshfs, gluster). Ideally it would work with stored metadata that can mostly function even if other users don't do this. And maybe work extra well if all users do use it. This is sort of like unison. For your use case, I think you should probably add FUSE to venus. This is probably not exceedingly hard, and I suspect it is easier than writing a kernel module. People will probably say that this will cause performance problems; the current kernel module forwards file operations in-kernel to the container file, so read/write are at native speed. That was probably very important back in 1997, and there was no FUSE then. But now, gluster via FUSE achieves near Gigabit speeds on NetBSD. And, I personally would far rather have filesystem that works on all the computers I want to use than to have it be fast on a few and totally nonfunctional on the rest. But, if venus has the current kernel interface and FUSE, those who want performance can use the present interface, or implement it on more systems. * I have no idea what that means for Windows. But Windows is outside my definition of "just about everywhere"...Received on 2015-01-28 11:48:54