From owner-freebsd-fs@FreeBSD.ORG Tue Dec 22 23:34:44 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 024A41065692; Tue, 22 Dec 2009 23:34:44 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id A5CA98FC08; Tue, 22 Dec 2009 23:34:43 +0000 (UTC) Received: by gxk10 with SMTP id 10so6474047gxk.3 for ; Tue, 22 Dec 2009 15:34:43 -0800 (PST) Received: by 10.101.144.2 with SMTP id w2mr14628588ann.158.1261524882959; Tue, 22 Dec 2009 15:34:42 -0800 (PST) Received: from ?10.0.1.198? (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id 22sm2574528ywh.30.2009.12.22.15.34.40 (version=SSLv3 cipher=RC4-MD5); Tue, 22 Dec 2009 15:34:42 -0800 (PST) Date: Tue, 22 Dec 2009 13:35:52 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Andrew Snow In-Reply-To: <4B302A6D.3000408@modulus.org> Message-ID: References: <712903.15604.qm@web113517.mail.gq1.yahoo.com> <3612709F-15CA-4A59-86B1-2674BAA2936D@gmail.com> <240049.46806.qm@web113517.mail.gq1.yahoo.com> <4B302A6D.3000408@modulus.org> 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 , jeff@FreeBSD.org Subject: Re: Plans for Logged/Journaled UFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2009 23:34:44 -0000 On Tue, 22 Dec 2009, Andrew Snow wrote: > > Is there any provision to put the journal on a seperate device? This can > solve the performance degradation issue. Currently there is no plan for it. The amount of journal data is so small compared to typical journaled filesystems I don't think we'll see a significant slowdown due to the journal writes. Consider the operation of creating a new file. We must write a cyl group to allocate a bitmap, an inode block to initialize the new inode, a directory block to add the entry, and potentially the directory inode to update timestamps, directory size, etc. So 4 block size writes if there is no directory allocation. The journal adds one 32byte entry to a block size write that can commonly hold 512 entries if you can aggregate them. Another way to look at it is that you can create 512 files (ignoring directory block allocation) before you need to write the journal. With full metadata block journaling you're writing the full size of each of those 4 blocks every time a change is made. On a 16k block filesystem that's 64k vs our 32 bytes. We can accomplish this because the recovery operation is smart enough to parse all the metadata and see how far along the operation is. Softupdates orders writes well enough that we only have to handle a small number of failure cases and can make big assumptions about the state of the filesystem. If any of these assumptions are not true we still have a full fsck to fall back on. Thanks, Jeff > > > - Andrew > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >