From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zach Brown Subject: CRFS source and project resources are now available Date: Tue, 11 Mar 2008 18:17:31 -0700 Message-ID: <47D72F2B.2010700@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To: linux-fsdevel@vger.kernel.org Return-path: Received: from tetsuo.zabbo.net ([207.173.201.20]:47957 "EHLO tetsuo.zabbo.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751258AbYCLBRb (ORCPT ); Tue, 11 Mar 2008 21:17:31 -0400 Received: from Macintosh.local (unknown [192.168.110.240]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tetsuo.zabbo.net (Postfix) with ESMTP id 288A4D12B21 for ; Tue, 11 Mar 2008 18:17:31 -0700 (PDT) Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hello everyone, Back at this year's LCA I gave a talk introducing CRFS, a cache coherent networked file system. http://linux.conf.au/programme/detail?TalkID=247 http://mirror.linux.org.au/pub/linux.conf.au/2008/Fri/mel8-247.ogg At the time of the talk the source wasn't available. It's now available in a mercurial repository, along with the usual set of mailing lists, at: http://oss.oracle.com/projects/crfs/ The project is still early alpha which is why I'm only sending this initial mail to -fsdevel. In the coming months it should stabilize and be more suitable for wider experimentation. Now is the time to get involved if you want to get your hands dirty in the initial design and implementation. I think the video recording of the talk does a decent job of giving an overview of the design, and it's a hoot, but I can give a quick summary: - the user space server exports a private BTRFS volume - the network protocol operates on ranges of BTRFS disk items - the kernel client provides posix semantics by operating on items - the server can grant and revoke client caches of data and metadata There's a lot of complexity hiding in those four lines but those are the critical properties to grasp :). The implementation has barely covered communicating item ranges between the server and the client. A single client can perform simple metadata and data read and write operations. Anything more complicated falls over pretty quickly. It's enough scaffolding to support divergent concurrent development, though. So, if this stuff interests you, do give it a try or share your thoughts over on the crfs- mailing lists. - z