From owner-freebsd-current@FreeBSD.ORG Fri Apr 23 08:28:43 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 532F0106564A for ; Fri, 23 Apr 2010 08:28:43 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7B78FC15 for ; Fri, 23 Apr 2010 08:28:42 +0000 (UTC) Received: by pwi9 with SMTP id 9so6864828pwi.13 for ; Fri, 23 Apr 2010 01:28:42 -0700 (PDT) Received: by 10.115.103.40 with SMTP id f40mr1244131wam.38.1272011322519; Fri, 23 Apr 2010 01:28:42 -0700 (PDT) Received: from [10.0.1.198] (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id b17sm3675330wam.10.2010.04.23.01.28.40 (version=SSLv3 cipher=RC4-MD5); Fri, 23 Apr 2010 01:28:41 -0700 (PDT) Date: Thu, 22 Apr 2010 22:28:43 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Garrett Cooper In-Reply-To: Message-ID: References: <20100421093940.3e6b181b@ernst.jennejohn.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2547152148-1430036841-1272011325=:1398" Cc: current@freebsd.org Subject: Re: HEADS UP: SUJ Going in to head today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 08:28:43 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2547152148-1430036841-1272011325=:1398 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 21 Apr 2010, Garrett Cooper wrote: > On Wed, Apr 21, 2010 at 12:39 AM, Gary Jennejohn > wrote: >> On Tue, 20 Apr 2010 12:15:48 -1000 (HST) >> Jeff Roberson wrote: >> >>> Hi Folks, >>> >>> You may have seen my other Soft-updates journaling (SUJ) announcements. >>> If not, it is a journaling system that works cooperatively with >>> soft-updates to eliminate the full background filesystem check after an >>> unclean shutdown.  SUJ may be enabled with tunefs -j enable and disabled >>> with tunefs -j disable on an unmounted filesystem.  It is backwards >>> compatible with soft-updates with no journal. >>> >>> I'm going to do another round of tests and buildworld this afternoon to >>> verify the diff and then I'm committing to head.  This is a very large >>> feature and fundamentally changes softupdates.  Although it has been >>> extensively tested by many there may be unforseen problems.  If you run >>> into an issue that you think may be suj please email me directly as well >>> as posting on current as I sometimes miss list email and this will ensure >>> the quickest response. >>> >> >> And the crowd goes wild. >> >> SUJ is _great_ and I'm glad to see it finally making it into the tree. > > Indeed. I'm looking forward to testing the junk out of this -- > this is definitely a good move forward with UFS2 :]... > Cheers, > -Garrett > > PS How does this interact with geom with journaling BTW? Has this been > tested performance wise (I know it doesn't make logistical sense, but > it does kind of seem to null and void the importance of geom with > journaling, maybe...)? > A quick update; I found a bug with snapshots that held up the commit. Hopefully I will be done with it tonight. About gjournal; there would be no reason to use the two together. There may be cases where each is faster. In fact it is very likely. pjd has said he thinks suj will simply replace gjournal. GEOM itself is no less important with suj in place as it of course fills many roles. Performance testing has been done. There is no regression in softdep performance with journaling disabled. With journaling enabled there are some cases that are slightly slower. It adds an extra ordered write so any time you modify the filesystem metadata and then require it to be synchronously written to disk you may wait for an extra transaction. There are ways to further improve the performance. In fact I did some experiments that showed dbench performance nearly identical to vanilla softdep if I can resolve one wait situation. Although this is not trivial it is possible. The CPU overhead ended up being surprisingly trivial in the cases I tested. Really the extra overhead is only when doing sync writes that allocate new blocks. I am eager to see wider coverage and hear feedback from more people. I suspect for all desktop and nearly all server use it will simply be transparent. Thanks, Jeff --2547152148-1430036841-1272011325=:1398--