Date: Mon, 23 Apr 2007 10:05:49 -0400 From: Greg Troxel <gdt@ir.bbn.com> To: Eric Anderson <anderson@freebsd.org> Cc: freebsd-fs@freebsd.org Subject: Re: distributed filesystems Message-ID: <rmi1wibrxs2.fsf@fnord.ir.bbn.com> In-Reply-To: <462CAE66.3050001@freebsd.org> (Eric Anderson's message of "Mon\, 23 Apr 2007 08\:02\:30 -0500") References: <20070422124731.GA20548@harmless.hu> <rmiy7kjs3o5.fsf@fnord.ir.bbn.com> <462CAE66.3050001@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-=-= [question about how to proceed] I'm answering on-list because I suspect this may be of broader interest. There is the kernel portion, and the userland code. You should build userland coda from coda's cvs (see attached scripts for NetBSD). This is lwp, rpc2, and rvm, and then coda itself (to get venus, the userland client-side cache manager). You'll want to join the coda mailing list and look at the web site and wiki. You just need a machine to run the client on. The server doesn't need kernel support and will be easier to re-port if necessary, but it's harder to set up from a coda point of view. There is a test server at CMU you can use your client with. In debugging the kernel code you are going to have crashes, so it's best if you can have a separate box (doesn't need to be fast) and even better if you can run kgdb. The NetBSD version is also old, with some recent updates. I think that NetBSD and FreeBSD have diverged in terms of vnode protocol, especially in foo_lookup, which is one of the harder routines. There is also the "realms support" issue. Coda uses a new venus/kernel protocol (version 3) that supports muliple coda realms (administrative domains). FreeBSD should be updated to that if it isn't already; the version 2 pre-realms version is now crufty and all coda people are using realms-capable venii. Big issues that I think you'll run into when porting the NetBSD version to FreeBSD are: vnode locking rules are different. NetBSD's rules have been regularized, with lookup taking a locked dvp and returning a locked vpp, leaving dvp locked, and fairly consistent vput for leaf operations. NetBSD has UVM, and so the interface to getpages/putpages is probably different. Coda passes a file by dev/ino into the kernel and then vnode ops on the coda vnode get forwarded to the (ffs) container file. This is tricky for handling page faults for executing a program, as the vnode isn't open. I am on the verge of doing a KNF reformat of the NetBSD code; it's quite clear that there's no upstream to merge from. I'm not aware of anyone in OpenBSD or Dragonfly hacking on coda either. So if you want to start from the NetSBD version I should probably do that. I suspect it would be ok to have things ifdef'd for FreeBSD so we could have one source file - if you want to try that path I can inquire within NetBSD about how that's handled. My guess is that aside from locking rule differences and getpages/putpages that the code will be very similar. Plus, we've gotten rid of some vnodeops, but I suspect they are unimplemented in coda anyway. I don't mean to putting down FreeBSD to be talking more about NetBSD - that's what I've been using lately and working on, and I'm therefore not clear on the current details for FreeBSD, having last run 4.x. I think there's enough common heritage still that my experience can be helpful, and I'd be thrilled if the fixed-up NetBSD bits can be snarfed into FreeBSD - a lot of code goes back and forth and that's a good thing. --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=coda-build.tgz Content-Transfer-Encoding: base64 H4sIACi6LEYAA+2X227TMBiAe7s8xU9BHbvIwW2TShsbDAbTpAoqtl4xkFLHaa0mcXCcbrw9tntY CozuIuvG8HeT2L9Pjfv5MCppEtkF5jQXReN+8Lyu1/N9+Wz7qKuenuf3Ovq5oIFkmaAd+H4QyHyE /AA1/HsazxplIUIO0BhH4q/lKN/GaLbOqDr/Lp4QPGWlsMMkqa8PD3m/zT/qdlfz30FoNf/dnqfm vxuoeH1DuJ27zn9ZEH5fgjwgz5+5I5q5xcSKGQcKNIPkKgee4zbwWQqYReEBRMwCCY3hC9gRvKDw 9QDEhGTWDsETBs3h4OT44uzjqQw1odWCl1iXkm94VoD9HcpcVbQHe7ohkhTE2tGhCPZz+WlnhO+H Gct+pKws3qheHVw4OC0dEpX7rsqwC47leGS7uo2YWhHLiEWuqQDPeugP+Y+y7r9O1eq+YpP/Unrp P/J7XqB2Cu2/p9aBeofxZ4z/d/V/bvrb4Vn/pGL6pYzc2K5SjjtiTBSCh7lTTJa5PAU7ls1lMR07 OJQ7zTLSP/nQPz49P2zafbcsuJtPx25CR2B/riab8G4wWBY8W0VohpMyIk3Z67ztkhOw7ZyTmF4f 6mIJw2GiV5Blj+M0nMpSU8AJCTOVW81stVYpmsl/R5LszVca9TOXzVSaoCQT9qIkzJcye1Xxsa9O 6/5HrMyjUJB6+9jkP/LlWbCHup1Ou+N7aOG/2f+3wY3/UlUbw66gKVEyVU6CcAR6f3/v9D+dQvuo hZQBjkuuc1YQe/6XgVfVQqsa5xfHF8NzaO1aj9eB/5lf/dfpmvvY5L8X9Cr+6/N/RyaN/1vgNv+X J0Fpst7xtdUL943LT4d1/9dW9Nr62OR/G6nzv4eCtvQ/0Pu/7/nI+L8FpP/qjKzXACIv6LFlPQdO UjYjkNCMFBBzlqq7Piz2+YSNZTIUcEXkvSDblS9hJkAwGWFTCIVlud8uX4Mbyae64i9u9zBU9Wk2 XgXmDa4FHvpzGAwGg8FgMBgMBoPBYDAYDE+KnylvWNoAKAAA --=-=-=--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?rmi1wibrxs2.fsf>