From owner-freebsd-current@FreeBSD.ORG Sat Jan 6 00:59:43 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DBD3316A403; Sat, 6 Jan 2007 00:59:43 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: from heave.ugcs.caltech.edu (heave.ugcs.caltech.edu [131.215.176.104]) by mx1.freebsd.org (Postfix) with ESMTP id C784B13C442; Sat, 6 Jan 2007 00:59:43 +0000 (UTC) (envelope-from jd@ugcs.caltech.edu) Received: by heave.ugcs.caltech.edu (Postfix, from userid 3640) id 5B9048F482; Fri, 5 Jan 2007 16:59:43 -0800 (PST) Date: Fri, 5 Jan 2007 16:59:43 -0800 From: Paul Allen To: Luigi Rizzo Message-ID: <20070106005943.GB8574@heave.ugcs.caltech.edu> References: <20070105123127.gnk0v58p44488g48@webmail.ntnu.no> <4085.1167997049@critter.freebsd.dk> <20070105184621.dh8kgoy7ko4gk4gc@webmail.ntnu.no> <20070105102905.A91349@xorpc.icir.org> <20070105212543.GA8574@heave.ugcs.caltech.edu> <20070105145915.B94175@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070105145915.B94175@xorpc.icir.org> Sender: jd@ugcs.caltech.edu Cc: freebsd-current@freebsd.org, lulf@stud.ntnu.no, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: Pluggable Disk Schedulers in GEOM 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: Sat, 06 Jan 2007 00:59:44 -0000 >From Luigi Rizzo , Fri, Jan 05, 2007 at 02:59:15PM -0800: > that does not mean that a scheduler is useless in general. > in fact, what i find questionable is hardwiring unnecessary > (in the sense that they are done only for performance reasons) > ordering constraints in the layers above. I cannot comment for I agree in so much as my point was strictly focused on ordering constraints imposed for consistency reasons. softupdates is not a performance mechanism per se; it is a mechanism to allow async writes of fs data occur in a consistent fashion. Anyways, you can easily resolve this issue by mounting async with softupdates disabled and then repeating the test.