From owner-freebsd-fs@FreeBSD.ORG  Thu Feb 10 22:56:32 2005
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id E566916A4CF; Thu, 10 Feb 2005 22:56:32 +0000 (GMT)
Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 24F1143D46; Thu, 10 Feb 2005 22:56:32 +0000 (GMT)
	(envelope-from julian@elischer.org)
Received: from elischer.org (julian.vicor-nb.com [208.206.78.97])
	by mail.vicor-nb.com (Postfix) with ESMTP
	id 139547A424; Thu, 10 Feb 2005 14:56:32 -0800 (PST)
Message-ID: <420BE69F.6070009@elischer.org>
Date: Thu, 10 Feb 2005 14:56:31 -0800
From: Julian Elischer <julian@elischer.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516
X-Accept-Language: en, hu
MIME-Version: 1.0
To: Dan Nelson <dnelson@allantgroup.com>
References: <20050210030119.GD29396@alzatex.com>
	<420AD3A7.3000102@freebsd.org> <20050210222114.GA40240@dan.emsphone.com>
In-Reply-To: <20050210222114.GA40240@dan.emsphone.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
cc: Scott Long <scottl@freebsd.org>
cc: fs@freebsd.org
Subject: Re: Journalling FS and Soft Updates comparision
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Feb 2005 22:56:33 -0000

uh.. isn't this backwards?

Dan Nelson wrote:

>
>This is the big drawback to softupdates for me.  You run the risk of
>losing the last `sysctl kern.metadelay` seconds worth of files, because
>of all the state that softupdates keeps in RAM.
>  
>

kern.filedelay: 30
kern.dirdelay: 29
kern.metadelay: 28

according to this we write the metadata first  and then the directory 
block and
then the file data..

This is just wrong. In softupdates you want to have your data down 
before you do
your metadata write,  and you need to have your directory block written 
last of all.
When I committed the softupdates code for Kirk, I think that the numbers 
were:
data in 10 seconds, metadata in 15 and directory block in 20.
(from memory).