From owner-freebsd-current@FreeBSD.ORG Thu Sep 1 16:06:23 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79255106566C for ; Thu, 1 Sep 2011 16:06:23 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 324A48FC0C for ; Thu, 1 Sep 2011 16:06:23 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1Qz9mX-00045X-Gi>; Thu, 01 Sep 2011 18:06:21 +0200 Received: from e178037248.adsl.alicedsl.de ([85.178.37.248] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1Qz9mX-00032M-DQ>; Thu, 01 Sep 2011 18:06:21 +0200 Message-ID: <4E5FAD7D.9030608@zedat.fu-berlin.de> Date: Thu, 01 Sep 2011 18:06:21 +0200 From: "Hartmann, O." User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.1) Gecko/20110901 Thunderbird/6.0.1 MIME-Version: 1.0 To: Ian FREISLICH References: <4E5F65CC.1090200@gmail.com> <4E5E70AF.2080806@zedat.fu-berlin.de> <4E5E773E.4050806@zedat.fu-berlin.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 85.178.37.248 Cc: Garrett Cooper , Niclas Zeising , freebsd-current Subject: Re: howto: enabling journaling on softupdates 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: Thu, 01 Sep 2011 16:06:23 -0000 On 09/01/11 13:26, Ian FREISLICH wrote: > Niclas Zeising wrote: >> Can you please detail a little more the steps you took to enable SU+J >> and your experience with it? It sounds like a good start for a howto or >> an inclusion in the handbook. > It's really simple... > > You need a kernel compiled with > options SOFTUPDATES # Enable FFS soft updates support > > In single-user mode or unmounted filesystems: > > tunefs -j enable > > Ian > Yes, it is really "THAT SIMPLE". But after enabling SU+J, I ran a "fsck" on the filesystem in question and I was asked wether I want to enable journaling and I had to type either n for NO or y for YES. One can avoid this by issuing "fsck -y". This is for selective enabling SU+J. If your're about to enable a bunch of filesystems, boot box in in singleuser, then type "tunefs -j enable /dev/gpt/blabla or whatever your partition in question is located at or simply the last mountpoint referred to in /etc/fstab.After having done this, issuing the command "fsck -y" performs a filsesystem check and enables SU+J. It is assumed, that suoftupdates are configured in the kernel via "options SOFTUPDATES", which is at least default in FreeBSD's GENERIC kernel config file for FreeBSD 9.0 and 8.2, as far as I know. And it is assumed that the filesystem in question on which you are about to enable softupdates-journaling already has softupdates enabled. If this isn't the case, perform all the steps above execpt issuing the tunefs-command sequence as follows: tunefs -n enable -j enable /dev/gpart/fsystem (/dev/gpt/ is used in my case since I switched on UFS2 filesystems to GPT partition tables). Beware! when reading the man page of tunefs, the first option for journaling that comes to your field of view is the capitalized "-J" which stands for journaling via GEOM/GJOURNAL, another method. Scroll further and you'll pick up the lower letter "-j", which is the option we are talking about here. It is a little bit confusing for the first approach). Once done, you can force on a non-important, big filesystem a crash. I switched of one of my server boxes with a 3 TB harddrive for test purposes and was amazed how fast, compared to unjournaled UFS2, the fsck now is performed. Since *BSDs UFS2/FFS filesystem is still, even for large disks/partitons, a competetive filesystem and still a slightly better performing filesystem compared to ZFS and its memory consumption, this efford is really worth "a must have". I'm simply overwealmed at this moment by this little pieces of more security and performance (in case of a crash on / and large partitions). A small piece, a great effect - I think. maybe naiv thinking, but who cares. Thanks to those who gave this pieces of bonbon to the community. Oliver