From owner-freebsd-arch@FreeBSD.ORG Sat Aug 27 12:24:13 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 9A6A81065675 for ; Sat, 27 Aug 2011 12:24:13 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 33CAF8FC1C for ; Sat, 27 Aug 2011 12:24:12 +0000 (UTC) Received: by wwi36 with SMTP id 36so4343828wwi.31 for ; Sat, 27 Aug 2011 05:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=RDMNnosI9KniBdB7WF2tbR4EhuP2E1SB7goIvMgHsRw=; b=PNLzFfRMAjWLKNzPDwkyP3ROoXp26csdPhZfcnefsmUYUfNMmCTBN5sblVFwcKVnf2 mLCwVx+G4VNdj/PA5qEXQtnocmGD5PrY+XZ+qsIxbqD9mPWEtzEL8NldKXCaCtpv/VUR 8AU5dbg1gTv08H0efkzW/MekPq6B23YdoedzM= MIME-Version: 1.0 Received: by 10.227.72.200 with SMTP id n8mr1083196wbj.19.1314446450094; Sat, 27 Aug 2011 05:00:50 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.227.206.139 with HTTP; Sat, 27 Aug 2011 05:00:50 -0700 (PDT) Date: Sat, 27 Aug 2011 14:00:50 +0200 X-Google-Sender-Auth: vbAIcujJKXBpup-9FAoZdXFwgU4 Message-ID: From: Attilio Rao To: freebsd-arch@freebsd.org, freebsd-current@freebsd.org, FreeBSD FS Content-Type: text/plain; charset=UTF-8 Cc: Robert Watson , Konstantin Belousov Subject: 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: Sat, 27 Aug 2011 12:24:13 -0000 [ Sorry for cross-posting, but I included -arch@ for technical discussion, -current@ for reaching the wider audience and -fs@ for the relevance of the matter.] During the last years a lot of effort by several developers happened in order to reduce Giant influence over the entire kernel. The VFS layer didn't make an exception, as many several tasks have been completed along the years, including fine-grained locking for vnodes lifecycle, fine-grained locking of the VFS structure (mount), fine-grained locking of specific filesystems (UFS, NFS, etc.) and several locking improvements to surrounding subsystem (buffer cache, filedesc objects, VM layer, etc.). While FreeBSD did pretty well so far, a major push is still needed in order to completely remove Giant from our VFS and buffer cache subsystems. At the present time, the biggest problem is that there are still filesystems which are not properly fine-grained locked, relying on Giant for assuring atomicity. It is time to make an decision for them, in order to aim for a Giant-less VFS in our next release. 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 As you can note from the page, the plan is thought to be 18 months long, including time for developers to convert all our filesystems and let thirdy-party producers do the same with their proprietary filesystems. Also the introduction (and later on removal) of VFS_GIANT_COMPATIBILITY is thought to stress-out the presence of not-yet MPSAFE filesystems used by consumers and force a proactive action. As you can note from the page, the list of filesystems to be converted is small and well contained, but there are some edge cases that really concerns me, like ntfs and smbfs. I took over leadership of ntfs, but if someone is willing to override myself, please just drop an e-mail and I'll happilly hand over someone else. About smbfs, I really think this is really the key filesystem we should fix in the list and it is time for someone to step up and do the job (including also locking and reworking netsmb). I knew there was a Google SoC going on this topic, but didn't have further updates to the matter in weeks. Ideally, after all the filesystems are locked, what should happen is to remove all Giant reference from the VFS, as kib's patch present in the wiki page. If some filesystem is still left for the 1st Semptember of next year, it is going to be disconnected from the tree along with Giant axing. As the locking of filesystems progresses, we can create subsections for each filesystems including technical notes on the matter. So fare there is none because the effort is still not started. The page is also thought to contain technical notes on how to operate the locking of filesystems, in more general way. I added the msdosfs example as a reference but other cases may have different problems. However, as the state of all the filesystems listed in the black page is a bit unknown, I'd suggest you to first make it work stable and just in the end work on locking. Also, please remind that locking doesn't need to be perfect at the first time, it is enough to bring the filesystem out of the Giant influence intially. Of course, for key filesystems (smbfs in primis) I'd expect to have full fine-grained locking support at some point. During the 18 months timeframe I'll send some reminder and status updates to these lists (monthly or bi-monthly). If there is anything else you want to discuss about this plan, don't hesitate to contact me. There is one last thing I want to stress out: this type of activities rely a lot on the audience to step up and make the job. Please don't expect someone else to fix the filesystem for you, but be proactive as much as you can, offering quality time for development, testing and reviews. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein