From owner-freebsd-arch@FreeBSD.ORG Mon Sep 12 11:08:21 2011 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A3A5106564A; Mon, 12 Sep 2011 11:08:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 33A0C8FC21; Mon, 12 Sep 2011 11:08:21 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id C63A746B17; Mon, 12 Sep 2011 07:08:20 -0400 (EDT) Date: Mon, 12 Sep 2011 12:08:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD FS , freebsd-current@freebsd.org, Konstantin Belousov , freebsd-arch@freebsd.org Subject: Call to arms: MPSAFE file systems (was: Re: Removal of Giant from the VFS layer for 10.0) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 11:08:21 -0000 On Sat, 27 Aug 2011, Attilio Rao wrote: > With the aid of kib and rwatson I made a roughly outlined plan about what is > left to do in order to have all the filesystems locked (or eventually > dropped) before 10.0) and is summarized here: > http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS Here's a more succinct summary of the key points from the wiki: FreeBSD has supported Giant lock-free file systems for years, and almost all file systems have been shipping "MPSAFE" for several years. However, VFS retains compatibility support for non-MPSAFE file systems. We want to remove that compatibility support, as it adds non-trivial complexity to an already quite complex VFS, simplifying the code and making it easier to maintain and enhance. This means either fixing or removing any file systems that can't operate without compatibility support. Attilio has posted a schedule for the removal of compatibility crutches, which in turn means removing any un-updated file systems. We are looking for volunteers to perform those updates. Here's the schedule: 27 August 2011 Attilio posts plan on arch@ 1 October 2011 Add VFS_GIANT_COMPATIBILITY option (enabled) 1 March 2012 Disable VFS_GIANT_COMPATIBILITY option by default 1 September 2012 Disconnect non-MPSAFE file systems from build 1 March 2013 Garbage collect any un-updated file systems Most of our critical file systems are already done: UFS, ZFS, the NFS client and server (both old and new), unionfs, pseudofs, tmpfs, nullfs, devfs, cd9660, ext2fs, fdescfs, msdosfs, udf, and procfs. However, some remain, and they require owners: File system Owner State coda rwatson Non-MPSAFE hpfs ??? Non-MPSAFE ntfs attilio Non-MPSAFE nwfs ??? Non-MPSAFE portalfs ??? Non-MPSAFE smbfs ??? Non-MPSAFE reiserfs ??? Non-MPSAFE xfs ??? Non-MPSAFE Any file system that remains on this list will be removed by 10.0 -- so, if you care about one of the above file systems, please help us get them updated. You can find more information here, including on the methodology for making a file system MPSAFE, with worked examples: http://wiki.freebsd.org/NONMPSAFE_DEORBIT_VFS Robert