From owner-cvs-src@FreeBSD.ORG Thu Jul 22 17:28:25 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C95B916A4CE; Thu, 22 Jul 2004 17:28:25 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 816DE43D39; Thu, 22 Jul 2004 17:28:25 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-63-195-111-154.dsl.snfc21.pacbell.net [63.195.111.154]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i6MHSNrb013314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Jul 2004 10:28:24 -0700 Message-ID: <40FFF8AF.5090805@root.org> Date: Thu, 22 Jul 2004 10:26:07 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <200407212045.i6LKjHvX090599@palm.tree.com> <40FEE569.2010209@elischer.org> <40FEE6CA.3090005@samsco.org> <20040722092441.GH3001@cirb503493.alcatel.com.au> <40FFEB86.2050209@root.org> <40FFF46A.2080703@freebsd.org> In-Reply-To: <40FFF46A.2080703@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Peter Jeremy cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/kern kern_shutdown.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2004 17:28:25 -0000 Scott Long wrote: > Nate Lawson wrote: >> Peter Jeremy wrote: >>> You still wind up with unwritten data in RAM, just less of it. >>> >>> How much effort would be required to add journalling to UFS or UFS2? >>> How big a gain does journalling give you over soft-updates? >> >> >> Kirk pointed out something to me the other day which many people don't >> think about. None of the journaling systems has had its recovery mode >> fully tested, especially on very large systems (dozen TB). It turns >> out that memory pressure from per-allocation unit state is a big >> problem when you are trying to recover a huge volume. >> >> Just because it says "journaling" doesn't make it good. > > You are very correct that there are issues like this, and that's why I > said that it would take a while to chase out the bugs and make it > production quality. However, given the enterprise nature of Sun, I'd > say it's a bit of a stretch to think that they haven't tested their > f/s on multi-terabyte arrays. I was referring to the herd of Linux journaling systems. > Even Apple advertises multi-terabyte > storage with their XServe, so I'd be surprised if they hadn't done at > least some testing there. > 2 TB? -- -Nate