From owner-freebsd-afs@FreeBSD.ORG Thu Jan 17 17:22:19 2008 Return-Path: Delivered-To: freebsd-afs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C6E416A41A; Thu, 17 Jan 2008 17:22:19 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 06DAB13C46A; Thu, 17 Jan 2008 17:22:18 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m0HHAAAv001430; Thu, 17 Jan 2008 10:10:10 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <478F8BF2.4070700@samsco.org> Date: Thu, 17 Jan 2008 10:10:10 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: Rick Macklem References: <18CC5A4A2AC36D7FF57615EE@ganymede.hub.org> <478AF6BC.8050604@highperformance.net> <20080114142124.Y55696@fledge.watson.org> <876FB8E38251C27B14CCCA29@atlantis.pc.cs.cmu.edu> <20080116203521.K15541@fledge.watson.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 17 Jan 2008 10:10:10 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org X-Mailman-Approved-At: Thu, 17 Jan 2008 17:39:15 +0000 Cc: rra@stanford.edu, port-freebsd@openafs.org, freebsd-fs@freebsd.org, Robert Watson , matt@linuxbox.com, freebsd-afs@freebsd.org, "Jason C. Wells" , openafs-devel@openafs.org, freebsd-questions@freebsd.org, Jeffrey Hutzelman Subject: Re: VFS KPI was Re: [OpenAFS-devel] Re: AFS ... or equivalent ... X-BeenThere: freebsd-afs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Andrew File System and FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2008 17:22:19 -0000 Rick Macklem wrote: > > > On Wed, 16 Jan 2008, Robert Watson wrote: > > [good stuff snipped] >> >> Right now we maintain a relatively stable VM/VFS KPI withing a major >> release (i.e, FreeBSD 6.0 -> 6.1 -> 6.2 -> 6.3), but see fairly >> significant changes between major releases (5.x -> 6.x -> 7.x, etc). >> I expect to see further changes in VFS for 8.x (and some of the >> locking-related ones have already started going in). >> > This is loosely related to both the OpenAFS thread and the Mac OS X ZFS > port thread, so I thought I'd ask... > > Has anyone considered trying to bring the FreeBSD VFS KPI (and others, for > that matter) closed to the Darwin/Mac OS X ones? The Apple folks made > quite dramatic changes to their VFS when going from Panther (very FreeBSD > like) to Tiger, but seemed to have stabilized, at least for Leopard. It > just seems that using the Mac OS X KPIs might leverage some work being > done on both sides? (I don't know if there is an OpenAFS port to Mac OS X > or interest in one, but I would think there would be a use for one, if it > existed?) > > Although I'm far from an expert on the Mac OS X VFS (when I ported to it, > I just cribbed the code and it worked:-), it seems that they pretty well > got rid of the concept of a vnode-lock. If the underlying file system > isn't SMP safe, it can put a lock on the subsystem at the VFS call. > (I think it optionally does a global lock or a uses an smp lock in the > vnode, but don't quote me on this. My code currently runs with the > thread-safe flag false in the vfs_conf structure entry, which enables > the automagic locking.) > Both Solaris and OSX seem to have found the path out of the VFS locking woods, and it would indeed be really nice if FreeBSD could follow suit. You're not the first to suggest the vnode locking move out of VFS and into the filesystems. I think that the work it would take to adapt the existing filesystems to this design would be far less than the ongoing work by everyone to fight the old design (both in FreeBSD proper and in companies that do their own custom filesystems in FreeBSD), but it does come at a cost of making things like nullfs much harder, if not nearly impossible. I wish I had time to work on something like this, but I encourage others to look into it and experiment. Scott